13.01.2023
25/09/26
Б-152
Сколько стоит аудит информационной безопасности: состав и стоимость
Две компании могут заказать аудит информационной безопасности и получить совершенно разные по объему проекты. 
В одном случае достаточно проверить документы и несколько ключевых процессов. 
В другом потребуется изучить распределенную инфраструктуру, провести интервью с владельцами систем, проверить настройки средств защиты и подготовить дорожную карту для нескольких подра зделений.
Поэтому стоимость аудита нельзя корректно определить только по количеству сотрудников, компьютеров или юридических лиц. Сначала необходимо понять, что именно проверяется, по каким критериям и какой результат нужен компании.

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

Что такое аудит информационной безопасности

Аудит информационной безопасности — это системная оценка того, как в организации устроена защита информациии насколько применяемые меры соответствуют установленным критериям.

Критериями могут выступать:

  • требования законодательства и регуляторов;
  • отраслевые и международные стандарты;
  • условия договора или тендера;
  • требования головной компании;
  • внутренние политики и регламенты;
  • заданный уровень зрелости;
  • актуальные для организации риски.

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

Методические подходы к оценке безопасности также предполагают, что процедуры проверки адаптируются под цели организации и ее риск-контекст. Например, NIST SP 800−53A Rev. 5 предусматривает возможность настраивать процедуры оценки с учетом задач организации и допустимого уровня риска.

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

Когда компании нужен аудит ИБ

Аудит информационной безопасности может потребоваться, когда необходимо:

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

Отсутствие инцидентов не означает, что аудит не нужен. Проблемы с доступами, резервным копированием, настройками, документацией и ответственностью подрядчиков могут долго не проявляться.
Задача аудита — обнаружить такие разрывы до того, как они приведут к нарушению работы или реализации угрозы.
Определите объем аудита до расчета стоимости
Границы, критерии и глубина проверки напрямую влияют на состав проекта. Предварительное обсуждение помогает понять, какие системы, процессы и технические проверки действительно нужно включить.

Какие виды аудита информационной безопасности существуют

Состав проверки зависит от ее цели. Под общим названием «аудит ИБ» могут скрываться разные проекты.

Аудит соответствия требованиям

Проводится, чтобы определить, выполняет ли организация конкретные обязательные или корпоративные требования.

Критериями могут быть нормативные акты, отраслевые стандарты, требования контрагента или внутренние документы компании. Аудитор фиксирует, какие требования выполняются, где обнаружены несоответствия и какие действия необходимы для их устранения.

Комплексный аудит ИБ

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

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

Обзор методов технического тестирования, их возможностей и ограничений приведен в NIST SP 800−115, опубликованном в 2008 году.

Аудит отдельных процессов

Компания может проверить не всю систему ИБ, а конкретное направление:

  • управление доступом;
  • работу с подрядчиками;
  • реагирование на инциденты;
  • резервное копирование;
  • управление изменениями;
  • управление уязвимостями;
  • использование облачных сервисов;
  • защиту персональных данных;
  • разработку программного обеспечения;
  • выполнение внутренних требований группы компаний.

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

Аудит безопасности информационных систем

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

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

Что входит в аудит информационной безопасности

Единого состава работ для всех проектов нет. Однако полноценный аудит обычно включает несколько этапов.

1. Определение целей и критериев

До начала проверки необходимо ответить на вопросы:

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

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

2. Определение границ проверки

В область аудита могут входить:

  • информационные системы;
  • серверы и рабочие станции;
  • сетевые сегменты;
  • сетевое оборудование;
  • облачные ресурсы;
  • сайты и приложения;
  • средства защиты информации;
  • подразделения и филиалы;
  • подрядчики с доступом к системам;
  • документы и локально-нормативные акты;
  • отдельные бизнес-процессы.

Граница должна быть зафиксирована однозначно. Формулировки вроде «проверить информационную безопасность компании» недостаточно: стороны могут по-разному понимать объем такой работы.

3. Сбор исходных данных

На этом этапе аудитор получает документы и сведения, необходимые для понимания системы защиты.

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

В зависимости от проекта могут запрашиваться:

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

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

4. Интервью и обследование процессов

Документы не всегда отражают реальную практику. Поэтому аудит может включать интервью с представителями:

  • руководства;
  • ИТ-службы;
  • подразделения информационной безопасности;
  • юридического и комплаенс-подразделений;
  • HR;
  • владельцами информационных систем;
  • разработчиками;
  • сотрудниками, взаимодействующими с подрядчиками.

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

5. Анализ документов

Аудитор проверяет:

  • наличие необходимых документов;
  • их актуальность;
  • соответствие выбранным требованиям;
  • согласованность документов между собой;
  • распределение ответственности;
  • соответствие регламентов реальной практике;
  • наличие подтверждений выполнения установленных процедур.

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

6. Проверка организационных и технических мер

В зависимости от области аудита может оцениваться:

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

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

7. Фиксация несоответствий и рисков

Аудитор должен не просто перечислить замечания, а объяснить:

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

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

Когда при аудите рассчитывают Кзи и Узи

Для отдельных информационных систем и значимых объектов КИИ результаты аудита могут использоваться не только для формирования перечня замечаний, но и при расчете показателей, предусмотренных методическими документами ФСТЭК России.

Кзи — показатель защищенности, характеризующий текущее состояние технической защиты информации и обеспечения безопасности информационных систем. Он показывает степень достижения минимально необходимого уровня защиты от типовых актуальных угроз. Нормированному значению соответствует Кзи = 1. Значение от 0,75 до 1 указывает на низкий уровень защищенности, а Кзи ≤ 0,75 — на критический.

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

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

До 1 сентября 2026 года в приказе ФСТЭК России № 117 использовалось обозначение Пзи. После вступления в силу изменений показатель уровня зрелости обозначается как Узи.

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

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

8. Подготовка отчета и дорожной карты

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

Если компании необходимо перейти от диагностики к изменениям, дополнительно формируется дорожная карта. Она может содержать:

  • перечень мероприятий;
  • приоритет;
  • рекомендуемую последовательность;
  • ответственные подразделения;
  • зависимости между задачами;
  • ожидаемый результат;
  • подтверждение выполнения.
В практике Б-152 встречались проекты, в которых аудит становился первым этапом более широкой работы. Например, для компании с распределенной инфраструктурой после оценки текущего состояния были подготовлены модель угроз, техническое задание, технический проект на создание системы защиты, локально-нормативные акты и обоснование необходимых мер защиты. Такой объем существенно отличается от проекта, который заканчивается только аудиторским отчетом.
Согласуйте состав проверки заранее
Можно определить, какие документы, процессы, системы и технические проверки должны войти в аудит и какой результат нужен компании — от перечня несоответствий до дорожной карты.

От чего зависит стоимость аудита информационной безопасности

Цель аудита

Проверка по одному конкретному требованию и комплексная оценка всей системы ИБ требуют разного объема работ. Чем больше целей объединено в одном проекте, тем шире программа аудита.

Перед расчетом важно определить, что нужно компании:

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

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

Количество и сложность объектов

На трудоемкость влияют:

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

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

Наличие актуальной инвентаризации

Если у компании есть актуальные схемы, реестры систем и перечни активов, аудитор быстрее определит область проверки.

Если сведения неполные или противоречат друг другу, в зависимости от целей и границ аудита может потребоваться дополнительное обследование:

  • определить перечень систем;
  • выявить неучтенные активы;
  • определить владельцев;
  • уточнить точки интеграции;
  • собрать сведения о доступах;
  • проверить фактические места обработки информации.

Инвентаризация в таком случае может стать самостоятельной частью и результатом проекта.

Выбранные требования и стандарты

Стоимость зависит от количества и сложности критериев, по которым проводится проверка.

Компания может одновременно оценивать соответствие:

  • требованиям российского законодательства;
  • требованиям отраслевого регулятора;
  • стандартам группы компаний;
  • договорным требованиям заказчика;
  • международным стандартам;
  • внутренним политикам.

Например, ISO/IEC 27 001:2022 устанавливает требования к системе менеджмента информационной безопасности: ее созданию, внедрению, поддержанию и постоянному совершенствованию, включая управление рисками информационной безопасности. Но аудит по этому стандарту не следует автоматически приравнивать к любому аудиту ИБ или к сертификационной оценке. Официальное описание стандарта доступно на сайте ISO.

Глубина технической проверки

Документарный анализ, выборочная проверка настроек и полноценное техническое обследование — это разные по трудоемкости задачи.

Необходимо заранее определить:

  • будут ли анализироваться конфигурации;
  • какие системы нужно проверять;
  • требуется ли сканирование уязвимостей;
  • входит ли проверка внешнего периметра;
  • требуется ли тестирование на проникновение;
  • допустимы ли активные воздействия;
  • нужна ли проверка устранения недостатков.

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

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

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

На трудоемкость влияют:

  • количество интервью;
  • продолжительность согласований;
  • доступность ответственных сотрудников;
  • необходимость повторных встреч;
  • противоречия между документами и фактической практикой.

Формат работы

Аудит может проводиться:

  • полностью удаленно;
  • с выездом на площадку;
  • в смешанном формате;
  • на одной площадке;
  • в нескольких филиалах.

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

Требования к результатам

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

На объем влияют:

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

Сроки

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

Что обычно не входит в аудит автоматически

Название услуги само по себе не подтверждает, что в проект включены:

  • пентест;
  • сканирование уязвимостей;
  • анализ исходного кода;
  • разработка модели угроз;
  • подготовка полного комплекта документов;
  • проектирование системы защиты;
  • подбор и внедрение средств защиты;
  • исправление технических настроек;
  • обучение сотрудников;
  • сопровождение устранения недостатков;
  • повторный аудит.

Каждую такую работу необходимо отдельно зафиксировать в техническом задании или составе проекта.

Как подготовиться к расчету стоимости

Чтобы исполнитель мог точнее оценить объем и стоимость работ, до обращения полезно подготовить следующие сведения:

  1. Цель аудита.
  2. Требования, по которым нужна проверка.
  3. Перечень информационных систем.
  4. Количество подразделений и площадок.
  5. Схему инфраструктуры.
  6. Перечень средств защиты.
  7. Список значимых подрядчиков.
  8. Информацию о собственных разработках и облачных сервисах.
  9. Результаты предыдущих аудитов.
  10. Сведения о существенных изменениях и инцидентах.
  11. Ожидаемый состав отчетных материалов.
  12. Необходимость технических проверок, дорожной карты и повторной оценки.

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

Как сравнивать предложения исполнителей

Независимая проверка особенно полезна, если организация давно не проводила аудит или инфраструктура существенно изменилась. Она может потребоваться при подготовке к проверке, тендеру или оценке заказчика, после серьезного инцидента, при недостатке отдельных компетенций внутри команды или когда необходимо проверить работу самого ИТ- или ИБ-подразделения.

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

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

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

Каким должен быть отчет по аудиту ИБ

Полезный отчет отвечает не только на вопрос «что не так», но и на вопрос «что делать дальше».

В него рекомендуется включать:

  • цель проверки;
  • область аудита;
  • используемые критерии;
  • проверенные объекты;
  • методы;
  • ограничения;
  • краткое резюме для руководства с ключевыми выводами, существенными рисками и приоритетными действиями;
  • выявленные несоответствия;
  • значения Кзи и Узи и основания их расчета, если оценка этих показателей входила в область аудита;
  • описание связанных рисков;
  • подтверждающие материалы;
  • рекомендации;
  • приоритеты;
  • зависимости между мероприятиями;
  • перечень вопросов, которые не удалось проверить.
В одном из проектов Б-152 результаты были разделены на три уровня: срочные риски, среднесрочные улучшения и задачи, связанные с дальнейшим развитием зрелости. Такая структура помогает не пытаться исправить все одновременно и направить ресурсы на наиболее значимые проблемы.

Частые вопросы

Можно ли определить стоимость аудита по количеству компьютеров?

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

Сколько времени занимает аудит информационной безопасности?

Единого срока нет. Он зависит от области аудита, готовности документов, количества интервью, сложности инфраструктуры, необходимости выезда и состава итоговых материалов.

Можно ли провести аудит удаленно?

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

Входит ли пентест в аудит ИБ?

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

Чем внутренний аудит отличается от внешнего?

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

К внешним относятся аудиты второй и третьей стороны. Аудит второй стороны может проводить, например, заказчик или другое заинтересованное лицо. Аудит третьей стороны проводится независимой внешней организацией, например сертификационным органом.

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

Чем аудит отличается от оценки рисков?

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

Нужно ли проводить аудит каждый год?

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

Может ли аудит гарантировать отсутствие инцидентов?

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

Главное

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

Поэтому начинать выбор аудита следует не с вопроса о цене, а с определения задачи:

  • что необходимо проверить;
  • по каким требованиям;
  • в каких границах;
  • какими методами;
  • какой результат должен получить бизнес.

Чем точнее сформулирована задача, тем прозрачнее состав работ и тем проще сравнить предложения разных исполнителей.
Материалы по теме