Аудит ИБ или оценка рисков: чем отличаются и какой формат нужен компании

Аудит информационной безопасности и оценку рисков часто воспринимают как одну и ту же проверку. На практике они отвечают на разные управленческие вопросы.

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

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

Материал актуален на 2026 год

Аудит и оценка рисков отвечают на разные вопросы

Если упростить различие, получится два сценария.

Аудит ИБ: «Что у нас есть сейчас и действительно ли это работает?»

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

Оценка рисков: «Что с нами может произойти и чем нужно заниматься в первую очередь?»

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

Результаты тоже разные.

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

После оценки рисков — перечень рассматриваемых рисков, их обоснование и приоритеты дальнейшей обработки.

Поэтому заменять одну работу другой не стоит. При этом в ряде проектов их логично объединять.

Что именно проверяют во время аудита ИБ

Аудит строится вокруг свидетельств.

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

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

В периметр проверки в зависимости от задачи могут входить:

1. архитектура информационных систем;
2. управление доступом;
3. резервное копирование;
4. журналирование;
5. реагирование на инциденты;
6. взаимодействие с подрядчиками;
7. средства защиты;
8. локальные нормативные документы.

Глубина работ зависит от цели.

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

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

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

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

Оценка рисков смотрит не только на текущее состояние защиты, но и на возможное развитие событий.

В зависимости от выбранной методики могут анализироваться:

1. активы;
2. угрозы;
3. уязвимости;
4. предрасполагающие условия;
5. существующие меры защиты;
6. вероятность реализации сценария;
7. потенциальные последствия.

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

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

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

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

NIST SP 800-30 указывает, что организация должна фиксировать подход к определению likelihood, используемые допущения, источники информации и обоснование итоговых оценок.

Поэтому универсальную шкалу риска нельзя просто перенести из другого проекта.

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

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

Аудит полезен, если руководству нужна подтвержденная картина текущего состояния защиты.

Например:

1. перед существенными изменениями инфраструктуры;
2. при подготовке к внешней проверке;
3. после инцидента;
4. когда нужно подтвердить фактическое выполнение требований;
5. если необходимо получить обоснованный перечень недостатков;
6. когда схемы и реестры систем давно не актуализировались.

Последний случай встречается особенно часто.

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

Без этого последующие выводы о состоянии защиты могут быть неполными.

Когда полезнее начинать с оценки рисков

Риск-анализ нужен прежде всего там, где компании необходимо выбрать приоритеты.

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

Такой формат особенно полезен:

1. при запуске новой системы;
2. при появлении новых категорий данных;
3. при подключении подрядчика;
4. при существенном изменении архитектуры;
5. при миграции в облачную инфраструктуру.

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

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

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

Когда аудит и оценку рисков лучше объединить

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

Последовательность выглядит так:

1. Проверить фактическую инфраструктуру и меры.

2. Зафиксировать выявленные недостатки и действующие механизмы защиты.

3. Использовать подтвержденную картину как исходные данные для оценки рисков.

4. Определить, какие риски и изменения наиболее существенны.

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

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

При этом объединять работы нужно не всегда.

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

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

Не уверены, с какой проверки начинать?

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

Определить формат проверки

А чем тогда отличаются пентест и анализ уязвимостей

Аудит и риск-анализ не стоит смешивать и с другими форматами технической проверки.

Пентест проверяет возможность реализации согласованных сценариев атаки в установленном периметре.

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

NIST SP 800-115 рассматривает penetration testing и vulnerability scanning как самостоятельные методы технического тестирования и оценки безопасности.

Аудит и оценка рисков могут охватывать более широкий контекст:

1. процессы;
2. роли;
3. документы;
4. зависимости;
5. последствия для бизнеса;
6. управленческие решения.

Результаты пентеста или сканирования уязвимостей при этом могут становиться входными данными для аудита и риск-анализа.

Главный вопрос снова заключается в цели.

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

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

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

Что компания должна получить в результате

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

Поэтому еще до старта проекта желательно согласовать:

1. структуру итогового документа;
2. критерии приемки;
3. уровень детализации доказательств;
4. формат рекомендаций.

После аудита

У компании должна появиться понятная картина:

1. что входило в периметр;
2. какие несоответствия обнаружены;
3. какие фактические недостатки выявлены;
4. на каких свидетельствах основан каждый вывод.

После оценки рисков

Должны быть зафиксированы:

1. рассматриваемые сценарии;
2. затронутые объекты и процессы;
3. оценка вероятности или правдоподобия;
4. последствия;
5. существующие меры;
6. приоритеты обработки рисков.

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

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

Когда стоит привлекать внешнего аудитора

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

Особенно это заметно в распределенной инфраструктуре.

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

Внешнее обследование помогает собрать эти сведения в единый периметр.

Но если задача требует именно независимой оценки, сам факт привлечения внешней компании еще не гарантирует независимость.

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

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

Уточните:

1. что именно входит в область проверки;
2. какими методами будут собираться свидетельства;
3. кто входит в команду;
4. какой доступ потребуется;
5. какой итоговый документ получит заказчик;
6. насколько рекомендации будут связаны с фактической инфраструктурой.

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

Что выбрать: аудит или оценку рисков

Ориентироваться можно на управленческий вопрос, который нужно решить.

«Насколько наша защита соответствует требованиям и как она работает сейчас?»

Нужен аудит.

«Какие события могут повлиять на компанию и чем заниматься в первую очередь?»

Нужна оценка рисков.

«Мы не уверены в фактическом состоянии инфраструктуры и хотим получить обоснованный план развития защиты».

Имеет смысл рассмотреть последовательное проведение обеих работ.

«Хотим проверить конкретный сценарий технической атаки».

Стоит рассматривать пентест.

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

Главное

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

Аудит дает подтвержденную свидетельствами картину текущего состояния. Риск-анализ помогает оценить возможные сценарии и последствия и на этой основе определить приоритеты.

Совмещать их имеет смысл, когда компании нужны и достоверные исходные данные, и обоснованный план дальнейших действий.

Если требуется определить периметр проверки и выбрать подходящий формат, специалисты Б-152 проводят технический аудит информационных систем с анализом документов, инфраструктуры, информационных систем и фактических процессов.