ТЗ на аудит ИБ: как описать периметр, задачи и требования к отчёту

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

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

Разберём, из чего состоит рабочее ТЗ на аудит ИБ: как описать периметр, как сформулировать задачи и какие требования к отчёту нужно зафиксировать заранее. Отдельно разберём структуру отчёта по пунктам — что в нём обязательно, а что заказывается дополнительно. Материал для ИТ-директоров, руководителей ИБ и тех, кто готовит закупку аудита впервые.

С чего начинается ТЗ: цель и нормативная рамка

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

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

Дальше указывается нормативная рамка. Здесь важно не переписать в ТЗ весь список документов из интернета, а назвать те, под которые компания реально попадает.

Для операторов персональных данных это 152-ФЗ. Цена вопроса заметно выросла: с 30 мая 2025 года утечка обходится юридическому лицу в 3–15 млн рублей, а повторная — в оборотный штраф 1–3% годовой выручки, но не менее 20 и не более 500 млн.

Для государственных информационных систем рамка изменилась совсем недавно. С 1 марта 2026 года действует приказ ФСТЭК России № 117 от 11 апреля 2025 года, который полностью заменил приказ № 17, действовавший с 2013 года. Подход другой: вместо разовой аттестации — регулярный расчёт показателей защищённости, оценка Кзи не реже раза в полгода, устранение уязвимостей критического уровня в срок не более 24 часов. Если в вашем ТЗ до сих пор упоминается приказ № 17, документ устарел.

Для субъектов КИИ действует 187-ФЗ с обновлённым порядком категорирования: постановление Правительства № 127 в редакции ПП № 1762 от 7 ноября 2025 года и типовые отраслевые перечни. Переоценка категории требуется не реже одного раза в пять лет, а на значимых объектах до 1 января 2030 года нужно перейти на доверенные программно-аппаратные комплексы.

Как описать периметр

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

Что перечислить

Внешний периметр: диапазоны IP-адресов, домены и поддомены, публичные веб-приложения с указанием URL, VPN-шлюзы, почтовые сервисы, всё, что доступно из интернета. Если у компании есть ресурсы у сторонних хостеров или в облаке, они указываются отдельно — на них потребуется согласие провайдера.

Внутренняя сеть: сегменты с указанием подсетей, количество узлов, ключевые серверы, контроллеры домена, АСУ ТП, если они есть. Для внутренних сегментов важно указать, откуда стартует проверка: из гостевого Wi-Fi, из пользовательского сегмента, из серверного.

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

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

Что зафиксировать в исключениях

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

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

Модель доступа

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

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

«Мы просим заказчика описать периметр до подписания договора, и на этом этапе примерно в половине случаев выясняется, что актуального перечня систем нет вообще. Тогда первым этапом идёт инвентаризация. Это дольше и дороже, но без неё аудит превращается в проверку того, что случайно вспомнили», — Олег Власенко, руководитель отдела информационной безопасности ОБИТ.

Задачи, методика и условия проведения

В блоке задач описывается, что именно исполнитель делает. Формулировки вроде «провести комплексный анализ защищённости» ничего не означают. Работают конкретные: инструментальное сканирование узлов периметра, ручная проверка выявленных уязвимостей на эксплуатируемость, анализ конфигураций средств защиты по чек-листу, проверка парольных политик, анализ сегментации сети, оценка соответствия по перечню требований.

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

• окна проведения активных работ — часы и дни, когда нагрузочные проверки допустимы;
• контактные лица с обеих сторон и канал экстренной связи на случай, если проверка вызвала сбой;
• порядок немедленного уведомления заказчика при обнаружении критической уязвимости или следов уже состоявшейся компрометации — не ждать финального отчёта;
• кто и в какие сроки предоставляет доступы, учётные записи и документацию;
• требования к исполнителю: лицензии ФСТЭК и ФСБ, квалификация команды, NDA, порядок хранения и уничтожения полученных данных.

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

Требования к отчёту: что обязательно, а что опционально

Отчёт — единственный материальный результат аудита, и требования к нему нужно писать так же подробно, как к периметру. Ниже — разбор по разделам.

Границы и методика

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

Резюме для руководства

Пишется на языке бизнеса: какие сценарии реализуемы, что при этом теряет компания, насколько срочно нужно вмешаться. В ТЗ имеет смысл прямо ограничить объём — одна-две страницы — и запретить в этом разделе технические термины без расшифровки. Именно этот кусок пойдёт на совет директоров и определит, выделят ли бюджет.

Описание каждой находки

Самый важный блок требований. Для каждой уязвимости в отчёте должны быть:

• уникальный идентификатор, по которому находку можно отслеживать в работе;
• привязка к конкретному активу: адрес, имя узла, URL, а не «сервер в тестовом сегменте»;
• описание сути и причины возникновения;
• пошаговое воспроизведение с командами и параметрами, чтобы администратор мог повторить проверку сам;
• подтверждение: скриншот, фрагмент лога, запрос и ответ;
• оценка критичности по CVSS с приведением вектора, а не только итогового балла;
• отдельная оценка влияния на бизнес: CVSS не знает, что этот сервер обслуживает отгрузку;
• конкретная рекомендация с указанием, что именно изменить, и оценкой трудоёмкости.

Требование приводить вектор CVSS, а не только число, стоит прописать отдельно. Вектор показывает, из чего сложилась оценка, и позволяет оспорить её, если исполнитель завысил критичность.

План устранения

Отчёт без плана — это список претензий. В ТЗ стоит потребовать разделить рекомендации на две группы: то, что закрывается настройками за несколько дней, и то, что требует проекта, бюджета и закупки. Внутри каждой группы — очередность с обоснованием, почему именно такая.

Формальные требования

Язык документа, формат передачи, срок предоставления после завершения работ, порядок доработки по замечаниям и количество итераций правок. Способ передачи отчёта отдельным пунктом: зашифрованный архив, защищённый канал, ограниченный список получателей. Отчёт об аудите — готовая инструкция по взлому вашей компании, и уходить по обычной почте он не должен.

«Требование приводить шаги воспроизведения меняет качество работы сильнее, чем любые другие пункты ТЗ. Когда исполнитель знает, что каждую находку заказчик повторит руками, из отчёта исчезают выводы сканера, скопированные без проверки. Проверяемость дисциплинирует лучше штрафов», — Олег Власенко, руководитель отдела информационной безопасности ОБИТ.

Ошибки, из-за которых ТЗ не работает

Периметр «вся инфраструктура». Звучит надёжно, а на деле означает, что объём не определён. Исполнитель заложит риск в цену или выполнит проверку поверхностно.

Требования к отчёту одной строкой. «Предоставить отчёт с рекомендациями» — исполнитель предоставит. Каким он будет, вы узнаете после оплаты.

Устаревшие ссылки на нормативы. После 1 марта 2026 года упоминание приказа ФСТЭК № 17 показывает, что ТЗ переписали из старого шаблона.

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

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

Порядок составления ТЗ

Последовательность, которая работает:

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

Если своей экспертизы для написания не хватает, нормальная практика — попросить у одного-двух потенциальных исполнителей обезличенный пример отчёта и структуру ТЗ. Серьёзные подрядчики такие материалы дают, и по ним сразу видно, что вы получите на выходе.

Мы помогаем сформулировать задание под конкретную инфраструктуру и нормативные требования, проводим аудит и передаём отчёт в формате, пригодном для работы, а не для полки. Расскажите о своей ситуации — обсудим, какой объём проверки нужен именно вам.