Отчёт, которым пользуются: как устроен результат ИТ-аудита и что с ним делать дальше

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

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

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

Что обязано быть в отчёте

Есть формальный ответ. ГОСТ Р ИСО 19011-2021 в пункте 6.5.1 перечисляет, что отчёт по аудиту должен содержать или на что ссылаться: цели аудита; область аудита с перечнем проверенных подразделений, процессов и охватываемого периода; идентификацию заказчика; состав группы аудиторов и участников со стороны проверяемой организации; даты и места работ; критерии аудита; выводы аудита; заключения по результатам; заявление о степени соответствия критериям.

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

Оговорка: сам ГОСТ Р ИСО 19011 написан про аудит систем менеджмента, а не про ИТ-инфраструктуру, и формально ИТ-аудит ему не подчиняется. Но структура отчётности в отрасли выросла именно оттуда, и перечень выше — хороший чек-лист для сверки того, что вам принесли.

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

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

Как устроен отчёт, которым пользуются

Рабочий отчёт собирают слоями под разных читателей. Генеральному директору нужны три страницы и решение, ИТ-директору — срез по направлениям, инженеру — конкретная находка с адресом сервера. Один документ обслуживает всех троих, если в нём прямо написано, кому какие страницы читать.

Именно приложения и создают те самые сто страниц, и это нормально: реестр активов и схемы нужны, их просто не читают подряд. Ненормально, когда приложения выданы за отчёт, а слоёв выше них не существует.

Как это выглядит на практике, видно по опубликованному отчёту об аудите ИТ-практик компании «Северная линия», который команда itsm4u выложила целиком. Двадцать страниц, пятнадцать разделов, и прямо в оглавлении написано, какие страницы читает правление, какие — ИТ-руководство, а какие нужны владельцам процессов. Первая страница даёт общий уровень зрелости — 2 из 5 — с расшифровкой одной строкой: привычки есть, но не описаны. Отдельный раздел показывает покрытие опроса и честно отмечает, где данных мало: например, служба ИБ дала 4 ответа из 8, и выводы по ней слабее.

Чего в отчёте быть не должно

Четыре признака, по которым документ опознаётся как нерабочий, причём все четыре встречаются и у крупных подрядчиков.

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

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

Находки без адресата. Раздел «выявленные недостатки» на десять страниц, после которого не следует ни одной задачи с исполнителем.

И обратная крайность — отчёт без приложений. Выводы есть, первичных данных нет, перепроверить нечего. Через полгода, когда администратор скажет «такого у нас не было», подтвердить находку будет нечем.

Анатомия одной находки

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

Поле «чем это грозит» заполняется тяжелее всех и чаще всего выхолащивается до штампа про риски непрерывности бизнеса. Разница видна сразу: «отсутствие проверки восстановления создаёт риски» — это ничто, а «последняя успешная проверка восстановления базы 1С не проводилась, при отказе хранилища срок возврата к работе неизвестен и может составить несколько суток» — это уже основание для решения.

«Простой способ проверить отчёт за десять минут: открыть три случайные находки и попробовать превратить каждую в задачу для конкретного человека. Если получается — отчёт рабочий. Если выходит задача вида "разобраться с безопасностью", значит, аудитор остановился на полпути и доделывать описание придётся вам», — Станислав Гуляев, ведущий технический эксперт ОБИТ.

Как расставлены приоритеты

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

Из чего складывается критичность

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

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

Сроки под каждый уровень

Отдельно задаются сроки под каждый уровень критичности. В аудитах информационной безопасности мы используем шкалу, где критичные находки закрываются за 7–14 дней, высокие — до 30 дней, средние — до 90, низкие — в течение года. Для ИТ-аудита логика та же, хотя конкретные сроки зависят от того, что именно нашли.

Что делать с тем, что решили не чинить

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

Критичное сообщают сразу

Критичные находки не ждут отчёта. ГОСТ Р ИСО 19011 прямо требует передавать свидетельства, указывающие на непосредственный и существенный риск, без задержки. Если на второй день обследования обнаружился доступ из интернета в контроллер домена, об этом сообщают в тот же день, а в отчёт это попадает уже вместе с отметкой, что проблема закрыта.

Как принимать отчёт у подрядчика

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

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

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

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

Что делать с отчётом дальше

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

Назначить владельцев

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

Превратить карту в план работ

Дорожная карта из отчёта — это предложение подрядчика, а не ваш план. Его нужно пересобрать под ваши реалии: убрать то, что уже делается, передвинуть то, что упирается в закупку или в сезон, разнести по кварталам с учётом бюджетного цикла. Часть пунктов при этом честно переезжает в статус «приняли риск, не делаем» — и это нормальное решение, если оно записано.

Поставить контрольную точку

Дата, на которую вы вернётесь к списку и посмотрите, что закрыто. Без неё к следующему аудиту выясняется, что сделана первая треть, а остальное забылось. Удобно привязывать контрольную точку к концу первой волны работ.

Запланировать повторный замер

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

«Отчёт живёт примерно год. Не потому, что устаревают выводы про процессы, а потому, что за год меняется матчасть: появляются новые системы, уезжают люди, закрываются одни узкие места и возникают другие. Через два года документ описывает инфраструктуру, которой уже нет, и спорить по нему бессмысленно», — Станислав Гуляев, ведущий технический эксперт ОБИТ.

Как подойти к заказу аудита

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

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

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