Короткий ответ
Техническое задание на средство защиты информации должно описывать задачу заказчика, среду эксплуатации, обязательные функции и способ проверить каждое требование. Для отдельного продукта и для создания системы защиты нужны разные границы работ: в первом случае описывают функции и взаимодействие выбранного класса средства, во втором — архитектуру, компоненты, интеграции и этапы создания системы. Не переносите требования из чужого тендера без проверки: состав и критерии приёмки должны соответствовать вашему объекту и задаче.
Сначала определите, что закупается
Перед составлением таблицы требований зафиксируйте предмет работ:
- отдельное средство защиты — например, система предотвращения утечек или средство мониторинга событий; важно описать сценарий использования, источники данных, интеграции и действия оператора;
- создание или развитие системы защиты — требуется описать несколько компонентов, взаимодействие между ними, среду, роли, обмен данными, миграцию и ввод в эксплуатацию;
- проектирование мер защиты конкретного объекта — исходные условия и применимые документы определяются самим объектом и его режимом; шаблон закупки СЗИ не заменяет проектную и регуляторную проработку.
Если речь о государственной информационной системе на платформе «ГосТех», у Минцифры есть отдельные методические рекомендации именно по разделам ТЗ для ГИС, создаваемых или развиваемых на этой платформе. Их область применения нельзя автоматически переносить на любую закупку СЗИ: официальный документ на платформе «ГосТех».
Что собрать до написания требований
- Перечень защищаемых процессов, систем и типов данных — в объёме, нужном для закупки.
- Среды, где будет работать решение: площадки, сети, ОС и ограничения эксплуатации, если они уже определены.
- Исходную схему: откуда поступают события и данные, какие системы должны получать результат, кто администрирует решение.
- Практические сценарии: что должен увидеть или сделать специалист при обычном событии, отказе компонента или изменении конфигурации.
- Ограничения проекта: сроки, этапность, окно внедрения, требования к переносу настроек и сохранению текущих процессов.
Не подменяйте этот сбор списком функций одного продукта. Сначала сформулируйте задачу, затем определите, какие классы средств и интеграции нужны для её решения.
Структура ТЗ: проверяемый каркас
| Раздел | Что зафиксировать | Чем проверить результат |
|---|---|---|
| Цель и границы | Какую задачу решает закупка и что в неё не входит | Согласованная граница проекта и перечень результатов |
| Объект и среда | Площадки, контуры, источники данных и условия эксплуатации | Проверка на тестовой или согласованной рабочей среде |
| Функциональные сценарии | Событие, ожидаемое действие системы, результат для оператора | Демонстрация сценария на заранее согласованных тестовых данных |
| Роли и управление | Кто настраивает, кто просматривает, кто утверждает изменения | Проверка доступа отдельными учётными записями и журналом действий |
| Интеграции | Источники, получатели, формат и направление обмена | Обмен тестовым сообщением или записью с подтверждением на принимающей стороне |
| Эксплуатация | Обновление, резервирование настроек, мониторинг состояния и восстановление | Регламентный сценарий и протокол проверки, согласованные до приёмки |
| Документы и передача | Какие схемы, инструкции и результаты работ передаются заказчику | Комплектность по заранее согласованному перечню |
| Этапы и приёмка | Что сдаётся на каждом этапе, кто проверяет и какие доказательства сохраняются | Матрица «требование → тест → результат → ответственный» |
Это рабочая структура для подготовки закупки, а не утверждённая государством форма и не универсальный нормативный перечень.
Как превратить пожелание в проверяемое требование
Формулировка «решение должно обеспечивать высокий уровень безопасности» не говорит исполнителю, что настроить, а заказчику — что принимать. Разложите её на конкретную потребность и проверку.
Пример матричной строки:
| Поле | Пример заполнения |
|---|---|
| Задача | Дежурный специалист должен получать события из согласованного источника |
| Требование | Передавать выбранные типы событий в согласованную систему мониторинга в документированном формате |
| Предусловие | Источник подключён; тестовая учётная запись и маршрут передачи доступны |
| Проверка | Сгенерировать контрольное событие, проверить его доставку и читаемость на принимающей стороне |
| Доказательство | Протокол теста с исходным событием, временем доставки и результатом разбора |
| Ответственный | Назначенный представитель заказчика и исполнитель на этапе приёмки |
Подставьте свои источники, роли и критерии. Не оставляйте числовые значения, сроки хранения или показатели производительности без расчёта и ответственного владельца.
Отдельное средство или система: где меняется содержание
Для отдельного класса — например, DLP, SIEM, антивируса или управления уязвимостями — ТЗ должно связывать функции с задачами и условиями заказчика. Сравнить состав рынка по классу можно в соответствующем каталоге классов СЗИ.
Для интегрированной системы добавьте границы компонентов, владельцев интеграций, совместный сценарий проверки и требования к передаче результата между компонентами. Не дублируйте одну и ту же функцию в разных разделах под разными названиями.
Для объекта КИИ отдельная проверка применимости регуляторных требований остаётся задачей профильных специалистов; справочный раздел о комплаенсе КИИ не заменяет такую оценку.
Частые ошибки заказчика
- копировать чужое ТЗ, не проверив, совпадают ли объект, среда и задача;
- указывать название конкретного решения вместо проверяемой потребности;
- писать общие оценки вроде «максимальная защита» без сценария и критерия приёмки;
- описывать функцию, но не указывать источник данных, роль оператора и ожидаемый результат;
- требовать интеграцию, не определив принимающую систему и способ теста;
- оставлять приёмку на конец проекта без промежуточных результатов и доказательств;
- смешивать покупку одного продукта с проектом создания системы защиты.
Чек-лист перед передачей ТЗ
- □ Зафиксированы задача и границы закупки.
- □ Описаны объект, среда и исходные ограничения.
- □ Функциональные требования привязаны к сценариям использования.
- □ Для каждого требования описана проверка и ожидаемое доказательство.
- □ Согласованы роли заказчика и исполнителя.
- □ Для каждой интеграции определены источник, получатель и тест обмена.
- □ Разделены требования к отдельному СЗИ и к интегрированной системе.
- □ Нормативные и закупочные формулировки проверены ответственными юристом и специалистом по ИБ применительно к объекту и процедуре.
Два сценария приёмки: от фразы до доказательства
Интеграция с системой мониторинга
Вместо «поддерживает SIEM» запишите конкретную цепочку: источник → транспорт → приёмник → правило разбора → действие оператора. Укажите версии компонентов, направление соединения, способ аутентификации и набор обязательных полей. Наличие коннектора в каталоге не подтверждает работу всей цепочки в вашей среде.
Для учебного теста создайте одно событие с уникальным идентификатором. Проверьте, что приёмник получил именно его, сохранил идентификатор источника и время, корректно разобрал обязательные поля. Затем кратко прервите соединение на тестовом стенде и проверьте предусмотренное поведение: очередь, повторную отправку или явное сообщение о потере. Если сохранение при разрыве не входит в требование, не считайте его автоматически обещанным.
В протоколе сохраните исходное событие, запись приёмника и журнал отправки. До теста согласуйте допустимую задержку, объём и длительность разрыва. Здесь нет универсальных числовых порогов: их определяет владелец процесса с учётом нагрузки и допустимых последствий.
Восстановление конфигурации после отказа
Вместо «имеется резервное копирование» перечислите, что восстанавливается: политики, роли, настройки интеграций, ключи или ссылки на внешнее хранилище секретов. Отдельно решите, входят ли события и история расследований. Наличие файла резервной копии ещё не доказывает восстановление работоспособности.
На изолированном стенде сохраните конфигурацию, затем восстановите её в согласованную версию компонента. Проверьте вход администратора и пользователя с ограниченными правами, применение одной контрольной политики и доставку тестового события. Запишите время восстановления и исключения: например, необходимость заново выдать токен внешней системы. Не используйте боевые секреты в общем протоколе.
Критерий приёмки формулируйте через результат: какие настройки совпали, какие сценарии снова работают, кто подтвердил восстановление. Если восстановление возможно только при участии поставщика, заранее зафиксируйте его действия, доступность и условия поддержки.
Рабочие файлы для своей закупки
Скачать матрицу требований CSV · Скачать проверочный список TXT
CSV содержит две учебные строки из этой статьи и пустую строку для собственного требования. Замените обозначения полей своими значениями; примеры не являются готовыми обязательными условиями договора. Для каждого требования назначьте владельца и сохраните связь с тестом. В TXT — короткий список проверки комплектности перед обсуждением проекта ТЗ.
Частые вопросы
Где взять образец ТЗ на средство защиты информации?
В выдаче встречаются документы из отдельных закупок и примеры для конкретных систем. Их можно использовать как материал для анализа структуры, но не как готовый универсальный шаблон. Проверьте предмет, среду, критерии приёмки и применимость каждого пункта к своей задаче.
Чем ТЗ на СЗИ отличается от ТЗ на систему защиты информации?
Для отдельного СЗИ задают функцию и условия применения конкретного класса решения. Для системы защиты дополнительно описывают компоненты, взаимосвязи, интеграции, этапы внедрения и совместную приёмку. Для конкретной закупки эти границы стоит прямо записать в разделе «Предмет и состав работ».
Нужно ли перечислять конкретные продукты?
Начните с задачи, функций, условий и способа проверки. Если закупочная процедура требует специальных формулировок, их должен проверить ответственный за закупку; эта статья не является юридической консультацией по процедуре.
Как проверить ТЗ до объявления закупки?
Проведите сквозной разбор: для каждого сценария найдите требование, для каждого требования — тест и доказательство результата. Затем проверьте документ вместе с будущими пользователями, администраторами, архитектором и ответственным за закупку.
Источник и область применения
Методические рекомендации Минцифры по разработке ТЗ для ГИС на платформе «ГосТех», версия 1.11, Москва, 2023: назначение и область применения — разделы 1.1–1.2, физические страницы 13–14 PDF. Документ относится к созданию и развитию ГИС на этой платформе. Мы не переносим его требования на любую закупку СЗИ и не утверждаем, что эта редакция является последней для вашего проекта. Официальный PDF.
Проверка источника: 8 октября 2026 года. Структура, примеры и файлы ниже — редакционные рабочие материалы SecRadar, а не нормативная форма. Применимость правовых и закупочных требований определяется отдельно для объекта и процедуры.