Власенко Олег Сергеевич

29.10.2026

План внутреннего аудита ИБ: структура документа и что в нём должно быть

Array ( [ID] => 3612 [~ID] => 3612 [IBLOCK_ID] => 36 [~IBLOCK_ID] => 36 [IBLOCK_SECTION_ID] => 105 [~IBLOCK_SECTION_ID] => 105 [NAME] => План внутреннего аудита ИБ: структура документа и что в нём должно быть [~NAME] => План внутреннего аудита ИБ: структура документа и что в нём должно быть [ACTIVE_FROM_X] => 2026-10-29 00:00:00 [~ACTIVE_FROM_X] => 2026-10-29 00:00:00 [ACTIVE_FROM] => 29.10.2026 [~ACTIVE_FROM] => 29.10.2026 [TIMESTAMP_X] => 29.10.2026 12:12:28 [~TIMESTAMP_X] => 29.10.2026 12:12:28 [DETAIL_PAGE_URL] => /blog/informatsionnaya-bezopasnost/plan-vnutrennego-audita-ib-struktura-dokumenta-i-chto-v-nyem-dolzhno-byt/ [~DETAIL_PAGE_URL] => /blog/informatsionnaya-bezopasnost/plan-vnutrennego-audita-ib-struktura-dokumenta-i-chto-v-nyem-dolzhno-byt/ [LIST_PAGE_URL] => /blog/ [~LIST_PAGE_URL] => /blog/ [DETAIL_TEXT] =>

План ИБ-аудита — документ, который превращает абстрактное намерение проверить безопасность в работу с границами, сроками и проверяемым результатом. Состав плана задан в пункте 6.3.2.2 ГОСТ Р ИСО 19011-2021, и там довольно короткий перечень из восьми обязательных элементов плюс необязательные, часть которых для ИБ-аудита обязательна на практике.

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

Программа и план: как они связаны

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

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

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

Состав программы задан пунктом 5.1 того же стандарта: цели программы, её риски и возможности, объём каждого аудита, график, типы аудитов, критерии, методы, критерии отбора аудиторов и относящаяся к программе документированная информация. Если программы пока нет, план первого аудита можно составить и без неё, но тогда в плане придётся определить и область, и критерии с нуля.

Структура плана: обязательные разделы

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

Шапка и идентификация

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

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

Цели аудита

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

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

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

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

Область аудита

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

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

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

Критерии аудита

Критерий — требование, с которым сравнивается фактическое состояние. В плане критерии либо перечисляются, либо даются ссылкой на реестр применимых требований, если он в компании есть.

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

Плохо: «парольная политика должна быть достаточной». Хорошо: «для всех учётных записей домена установлена минимальная длина пароля не менее 12 символов, блокировка после 5 неудачных попыток, запрет повторного использования последних 5 паролей».

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

Документированная информация к рассмотрению

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

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

Методы и объём выборки

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

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

привилегированные и сервисные учётные записи — 100%, их обычно десятки;
учётные записи уволенных за период — 100%, это и есть предмет проверки;
обычные пользовательские записи — выборка, например 10% или не меньше 30 записей, в зависимости от того, что больше;
заявки на доступ за период — выборка по 5–10 заявок на каждый месяц;
рабочие места — выборка по одному-двум на подразделение и площадку.

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

Места, даты и график работ

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

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

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

Состав группы, роли и ресурсы

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

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

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

Разделы, которые стандарт называет дополнительными

Стандарт разрешает включить в план дополнительные пункты. Для ИБ-аудита три из них обязательны практически, потому что без них проверка создаёт риск сама по себе.

Обращение с материалами проверки

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

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

Меры снижения рисков самой проверки

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

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

Действия по итогам предыдущих аудитов

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

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

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

Как выглядит заполненный план

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

Раздел	Заполнение
Идентификация	План № 3 к программе аудитов на 2026 год, п. 2.3. Составлен 10.02.2026, версия 1.0
Цели	Установить соответствие фактической модели доступа утверждённой матрице ролей; подтвердить блокировку прав уволенных в срок регламента
Область	Подразделения: продажи, финансы, склад. Системы: домен corp.local, 1С:УТ, CRM, файловый сервер FS-01. Процессы: предоставление, отзыв и ревизия прав. Состояние на 01.02.2026, события с 01.08.2025
Исключения	Тестовый контур, филиальные серверы, облачные сервисы подрядчиков
Критерии	Политика управления доступом ПБ-04, разделы 4–6; матрица ролей от 12.09.2025; требование блокировки учётной записи в день увольнения
Запрашиваемые документы	ПБ-04, матрица ролей, выгрузка пользователей и групп на 01.02.2026, список уволенных с 01.08.2025, журнал заявок, перечень привилегированных записей
Методы и выборка	Сверка выгрузки каталога со списком кадровой службы — 100%; привилегированные записи — 100%; пользовательские — 10%, не менее 30; заявки — 5 на месяц. Расширение выборки вдвое при двух и более несоответствиях
График	16.02 вступительная встреча, 16–20.02 сбор данных, 23–25.02 анализ, 26.02 заключительная встреча, 02.03 отчёт
Группа и независимость	Руководитель группы — специалист ИБ; аудитор — инженер ИТ, не администрирует системы из области; сопровождающие — владельцы процессов в подразделениях
Ресурсы и доступы	Учётная запись с правами чтения в домене, доступ на чтение к журналу заявок, 4 часа времени каждого владельца процесса
Обращение с материалами	Рабочие материалы в закрытом разделе файлового сервера, доступ у двух участников, выгрузки удаляются через 30 дней после утверждения отчёта
Итоги предыдущих аудитов	Проверить закрытие находок № 7 и № 12 плана № 1 за 2025 год

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

Решение

Аудит ИТ-инфраструктуры

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

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

Повторяются от компании к компании почти дословно.

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

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

Как составить план

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

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

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

Решение

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

Помогаем выстроить программу аудитов и провести независимую проверку с лицензиями ФСТЭК и ФСБ: критерии, чек-листы, свидетельства и отчёт с приоритетами и планом устранения.

Часто задаваемые вопросы (FAQ)

Что должно быть в плане внутреннего аудита информационной безопасности?

Пункт 6.3.2.2 ГОСТ Р ИСО 19011-2021 требует восьми элементов: цели аудита, область, критерии и запрашиваемая документированная информация, места и даты с продолжительностью работ, необходимость ознакомления группы с процессами, методы с объёмом выборки, роли и обязанности участников, распределение ресурсов. Для ИБ-аудита к ним добавляются три практически обязательных раздела: обращение с материалами проверки, меры снижения рисков самой проверки и действия по итогам предыдущих аудитов.
Чем план аудита отличается от программы аудитов?

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

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

Четырьмя перечнями: организационным (подразделения, филиалы, площадки), техническим (конкретные системы с идентификаторами из реестра активов), процессным (какие процессы проверяются) и временным — на какую дату берётся состояние и за какой период анализируются события. Отдельным абзацем фиксируются исключения: что в область не входит и почему. Незафиксированное исключение превращается в претензию при приёмке результата.
Как задать объём выборки в плане аудита?

Стратифицированно: совокупность делится на группы по критичности, и для каждой задаётся свой охват. Привилегированные и сервисные учётные записи — 100%, учётные записи уволенных за период — 100%, обычные пользовательские — например 10% или не меньше 30 записей, заявки на доступ — по 5–10 на каждый месяц, рабочие места — одно-два на подразделение. Отдельно задаётся правило расширения: при двух и более несоответствиях выборка по группе увеличивается вдвое.
Какие разделы нужны в плане именно для ИБ-аудита?

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

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

[~DETAIL_TEXT] =>

План ИБ-аудита — документ, который превращает абстрактное намерение проверить безопасность в работу с границами, сроками и проверяемым результатом. Состав плана задан в пункте 6.3.2.2 ГОСТ Р ИСО 19011-2021, и там довольно короткий перечень из восьми обязательных элементов плюс необязательные, часть которых для ИБ-аудита обязательна на практике.

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

Программа и план: как они связаны

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

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

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

Состав программы задан пунктом 5.1 того же стандарта: цели программы, её риски и возможности, объём каждого аудита, график, типы аудитов, критерии, методы, критерии отбора аудиторов и относящаяся к программе документированная информация. Если программы пока нет, план первого аудита можно составить и без неё, но тогда в плане придётся определить и область, и критерии с нуля.

Структура плана: обязательные разделы

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

Шапка и идентификация

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

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

Цели аудита

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

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

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

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

Область аудита

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

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

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

Критерии аудита

Критерий — требование, с которым сравнивается фактическое состояние. В плане критерии либо перечисляются, либо даются ссылкой на реестр применимых требований, если он в компании есть.

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

Плохо: «парольная политика должна быть достаточной». Хорошо: «для всех учётных записей домена установлена минимальная длина пароля не менее 12 символов, блокировка после 5 неудачных попыток, запрет повторного использования последних 5 паролей».

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

Документированная информация к рассмотрению

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

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

Методы и объём выборки

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

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

привилегированные и сервисные учётные записи — 100%, их обычно десятки;
учётные записи уволенных за период — 100%, это и есть предмет проверки;
обычные пользовательские записи — выборка, например 10% или не меньше 30 записей, в зависимости от того, что больше;
заявки на доступ за период — выборка по 5–10 заявок на каждый месяц;
рабочие места — выборка по одному-двум на подразделение и площадку.

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

Места, даты и график работ

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

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

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

Состав группы, роли и ресурсы

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

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

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

Разделы, которые стандарт называет дополнительными

Стандарт разрешает включить в план дополнительные пункты. Для ИБ-аудита три из них обязательны практически, потому что без них проверка создаёт риск сама по себе.

Обращение с материалами проверки

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

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

Меры снижения рисков самой проверки

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

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

Действия по итогам предыдущих аудитов

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

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

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

Как выглядит заполненный план

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

Раздел	Заполнение
Идентификация	План № 3 к программе аудитов на 2026 год, п. 2.3. Составлен 10.02.2026, версия 1.0
Цели	Установить соответствие фактической модели доступа утверждённой матрице ролей; подтвердить блокировку прав уволенных в срок регламента
Область	Подразделения: продажи, финансы, склад. Системы: домен corp.local, 1С:УТ, CRM, файловый сервер FS-01. Процессы: предоставление, отзыв и ревизия прав. Состояние на 01.02.2026, события с 01.08.2025
Исключения	Тестовый контур, филиальные серверы, облачные сервисы подрядчиков
Критерии	Политика управления доступом ПБ-04, разделы 4–6; матрица ролей от 12.09.2025; требование блокировки учётной записи в день увольнения
Запрашиваемые документы	ПБ-04, матрица ролей, выгрузка пользователей и групп на 01.02.2026, список уволенных с 01.08.2025, журнал заявок, перечень привилегированных записей
Методы и выборка	Сверка выгрузки каталога со списком кадровой службы — 100%; привилегированные записи — 100%; пользовательские — 10%, не менее 30; заявки — 5 на месяц. Расширение выборки вдвое при двух и более несоответствиях
График	16.02 вступительная встреча, 16–20.02 сбор данных, 23–25.02 анализ, 26.02 заключительная встреча, 02.03 отчёт
Группа и независимость	Руководитель группы — специалист ИБ; аудитор — инженер ИТ, не администрирует системы из области; сопровождающие — владельцы процессов в подразделениях
Ресурсы и доступы	Учётная запись с правами чтения в домене, доступ на чтение к журналу заявок, 4 часа времени каждого владельца процесса
Обращение с материалами	Рабочие материалы в закрытом разделе файлового сервера, доступ у двух участников, выгрузки удаляются через 30 дней после утверждения отчёта
Итоги предыдущих аудитов	Проверить закрытие находок № 7 и № 12 плана № 1 за 2025 год

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

Решение

Аудит ИТ-инфраструктуры

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

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

Повторяются от компании к компании почти дословно.

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

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

Как составить план

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

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

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

Решение

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

Помогаем выстроить программу аудитов и провести независимую проверку с лицензиями ФСТЭК и ФСБ: критерии, чек-листы, свидетельства и отчёт с приоритетами и планом устранения.

Часто задаваемые вопросы (FAQ)

Что должно быть в плане внутреннего аудита информационной безопасности?

Пункт 6.3.2.2 ГОСТ Р ИСО 19011-2021 требует восьми элементов: цели аудита, область, критерии и запрашиваемая документированная информация, места и даты с продолжительностью работ, необходимость ознакомления группы с процессами, методы с объёмом выборки, роли и обязанности участников, распределение ресурсов. Для ИБ-аудита к ним добавляются три практически обязательных раздела: обращение с материалами проверки, меры снижения рисков самой проверки и действия по итогам предыдущих аудитов.
Чем план аудита отличается от программы аудитов?

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

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

Четырьмя перечнями: организационным (подразделения, филиалы, площадки), техническим (конкретные системы с идентификаторами из реестра активов), процессным (какие процессы проверяются) и временным — на какую дату берётся состояние и за какой период анализируются события. Отдельным абзацем фиксируются исключения: что в область не входит и почему. Незафиксированное исключение превращается в претензию при приёмке результата.
Как задать объём выборки в плане аудита?

Стратифицированно: совокупность делится на группы по критичности, и для каждой задаётся свой охват. Привилегированные и сервисные учётные записи — 100%, учётные записи уволенных за период — 100%, обычные пользовательские — например 10% или не меньше 30 записей, заявки на доступ — по 5–10 на каждый месяц, рабочие места — одно-два на подразделение. Отдельно задаётся правило расширения: при двух и более несоответствиях выборка по группе увеличивается вдвое.
Какие разделы нужны в плане именно для ИБ-аудита?

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

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

Читать

Информационная безопасность

28.10.2026

Аудит ИБ своими силами: что реально сделать самим и где начинаются границы

Array ( [ID] => 3611 [~ID] => 3611 [IBLOCK_ID] => 36 [~IBLOCK_ID] => 36 [IBLOCK_SECTION_ID] => 105 [~IBLOCK_SECTION_ID] => 105 [NAME] => Аудит ИБ своими силами: что реально сделать самим и где начинаются границы [~NAME] => Аудит ИБ своими силами: что реально сделать самим и где начинаются границы [ACTIVE_FROM_X] => 2026-10-28 00:00:00 [~ACTIVE_FROM_X] => 2026-10-28 00:00:00 [ACTIVE_FROM] => 28.10.2026 [~ACTIVE_FROM] => 28.10.2026 [TIMESTAMP_X] => 28.10.2026 19:02:22 [~TIMESTAMP_X] => 28.10.2026 19:02:22 [DETAIL_PAGE_URL] => /blog/informatsionnaya-bezopasnost/audit-ib-svoimi-silami-chto-realno-sdelat-samim-i-gde-nachinayutsya-granitsy/ [~DETAIL_PAGE_URL] => /blog/informatsionnaya-bezopasnost/audit-ib-svoimi-silami-chto-realno-sdelat-samim-i-gde-nachinayutsya-granitsy/ [LIST_PAGE_URL] => /blog/ [~LIST_PAGE_URL] => /blog/ [DETAIL_TEXT] =>

Можно ли самостоятельно провести ИБ-аудит? Короткий ответ: да, значительную часть аудита информационной безопасности компания может провести сама, и для персональных данных закон это прямо разрешает. Более того, самостоятельная проверка закрывает как раз самый массовый класс проблем. По результатам проверок защищённости, которые Positive Technologies опубликовала в октябре 2026 года, ошибки конфигурации встречались более чем в два раза чаще уязвимостей, подходящие логины и пароли открывали доступ к важным системам в 56% успешных сценариев, а пароли в открытом виде нашлись в 77% проверок. Это не экзотика, которую видно только специализированным инструментом, а то, что администратор способен найти своими руками.

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

Где закон разрешает своими силами, а где нет

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

Опорный случай — персональные данные. Пункт 6 приказа ФСТЭК России № 21 устанавливает, что оценка эффективности реализованных мер по обеспечению безопасности персональных данных проводится оператором самостоятельно или с привлечением на договорной основе организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации, и не реже одного раза в три года. То есть для самого распространённого режима выбор остаётся за оператором.

Режим требований	Кто может проводить	Периодичность
Персональные данные, приказ ФСТЭК № 21	оператор самостоятельно либо лицензиат ТЗКИ	не реже раза в 3 года
Критическая информационная инфраструктура, 187-ФЗ	категорирование проводит внутренняя комиссия субъекта	по правилам постановления № 127
Государственные информационные системы	аттестация — только лицензиат ФСТЭК	при вводе в эксплуатацию и при изменениях
Финансовый сектор, ГОСТ Р 57580	по положениям Банка России, для банков — внешняя проверяющая организация	задаётся положением
ISO 27001 и ГОСТ Р ИСО/МЭК 27001	внутренний аудит обязателен и проводится самой организацией, сертификация — орган по сертификации	внутренний регулярно, сертификационный по циклу
Регуляторных требований нет	любой формат, включая полностью внутренний	по решению компании

Два пояснения к таблице. Для финансовых организаций порядок задают положения Банка России, и там он самый строгий: для банков с 29 марта 2025 года действует Положение № 851-П, заменившее 683-П, для некредитных организаций — Положение № 757-П. Состав допустимых исполнителей оценки и её периодичность нужно смотреть в актуальной редакции своего положения, потому что требования к внешнему исполнителю здесь жёстче, чем в остальных режимах.

По критической инфраструктуре принцип обратный и часто неожидаемый: категорирование объектов субъект КИИ проводит сам, силами собственной комиссии. Правила категорирования менялись, поэтому действующую редакцию постановления № 127 стоит сверить перед началом работ.

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

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

Инвентаризация активов и внешнего периметра

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

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

Ревизия прав доступа и учётных записей

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

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

Решение

Внедрение IdM и PAM-систем

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

Пароли и парольные политики

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

Именно здесь результаты самостоятельной проверки совпадают с тем, что находят профессиональные проверяющие. В исследовании Positive Technologies учётные данные обнаруживались в 96% компаний, а в 77% проверок находились пароли в открытом виде. Поиск по общим папкам и репозиториям на характерные строки — работа на несколько часов, а эффект сопоставим с серьёзным проектом.

Обновления и конфигурации

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

Масштаб проблемы хорошо видно по той же статистике: в 21% проверок использовалась уязвимость, найденная ещё в 2021 году, а в 14% — уязвимость, исправление для которой вышло в 2017-м. Такие находки не требуют пентеста, достаточно сверить версии со списком и посмотреть, где не ставились обновления.

Доступ извне и сегментация

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

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

Устойчивость к фишингу

Почта остаётся основным входом: по данным BI.Zone, которые приводил «Коммерсантъ» в мае 2026 года, с электронной почты начинаются 68% целевых атак. Самостоятельно здесь проверяется техническая часть и организационная.

Техническая: настроены ли SPF, DKIM и DMARC для своих доменных имён, фильтруются ли вложения опасных типов, доходят ли письма с подменённым адресом отправителя от имени своих же руководителей. Последнее проверяется одним тестовым письмом.

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

Резервные копии и журналирование

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

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

Чем это делать

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

Кто внутри компании может провести ИБ-аудит

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

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

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

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

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

Где начинаются границы

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

Независимость

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

В ряде режимов независимость — формальное требование, и тогда вопрос снимается сам. Там, где требования нет, помогает хотя бы разделение внутри компании: проверяет не тот, кто настраивал.

Квалификация в анализе защищённости

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

Показательна статистика векторов из того же исследования: перенаправление чужой попытки входа дало результат в 35% успешных сценариев. Такую атаку не найти ревизией прав или сверкой версий, для неё нужен человек, который умеет её выполнять. И общий результат проверок говорит о том же: в 60% компаний удалось захватить компьютер или сервер, получить доступ к важным данным либо взять под контроль Active Directory, причём в половине случаев на это ушло 13 минут.

Юридическая сила результата

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

Это стоит понимать до начала работ, чтобы не получить ситуацию, когда проверка проведена честно и полно, а предъявить её нечему.

Инструментальный охват

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

Как оформить результат, чтобы он работал

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

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

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

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

Гибридная схема, которая обычно и работает

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

Работа	Кто делает	Периодичность
Ревизия прав и учётных записей	своими силами	раз в квартал
Обновления и неподдерживаемые системы	своими силами	раз в квартал
Контроль резервного копирования с пробным восстановлением	своими силами	раз в квартал
Перечень активов и внешний периметр	своими силами	раз в квартал
Парольная гигиена и поиск паролей в открытом виде	своими силами	раз в квартал
Анализ защищённости и тестирование на проникновение	внешняя организация	раз в год
Независимая оценка архитектуры и процессов	внешняя организация	раз в 2–3 года
Оценка соответствия требованиям	внешняя организация там, где это предписано	по своему режиму
Аттестация и сертификация	лицензиат ФСТЭК или орган по сертификации	по циклу

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

Как подойти к решению

Провести аудит информационной безопасности своими силами можно, и для большинства компаний это правильный первый шаг. Самостоятельно закрываются инвентаризация, ревизия доступов, парольная гигиена, контроль обновлений, резервные копии и журналирование, а по персональным данным оценка эффективности мер прямо разрешена пунктом 6 приказа ФСТЭК № 21. Нельзя сделать самостоятельно три вещи: получить независимое заключение, провести полноценный анализ защищённости и выполнить работы, требующие лицензии, — аттестацию, сертификацию и оценку по требованиям Банка России.

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

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

Решение

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

Проводим независимую проверку с лицензиями ФСТЭК и ФСБ: смотрим то, что внутренняя команда закрыть не может, и отдаём отчёт с находками, приоритетами и планом устранения.

Часто задаваемые вопросы (FAQ)

Можно ли провести аудит информационной безопасности своими силами, без подрядчика?

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

Пункт 6 приказа ФСТЭК России № 21 прямо допускает оба варианта: оценка эффективности реализованных мер по обеспечению безопасности персональных данных проводится оператором самостоятельно либо с привлечением по договору организации, имеющей лицензию на техническую защиту конфиденциальной информации. Периодичность — не реже одного раза в три года. Результат оформляется актом оценки эффективности мер.
Какие проверки дают наибольший результат при самостоятельном аудите?

Ревизия учётных записей и прав, поиск паролей в открытом виде и проверка сетевой достижимости систем управления с обычного рабочего места. По результатам проверок защищённости Positive Technologies за октябрь 2026 года учётные данные находились в 96% компаний, пароли в открытом виде — в 77% проверок, а ошибки конфигурации встречались более чем в два раза чаще уязвимостей. Это тот класс проблем, который виден без пентеста.
Почему внутренняя проверка не заменяет внешнюю?

По четырём причинам: внутренняя команда проверяет собственную работу и не видит ошибок в решениях, которые сама считает верными; анализ защищённости требует отдельной квалификации, и сценарии вроде перенаправления чужой попытки входа (35% успешных векторов у Positive Technologies) ревизией прав не находятся; внутренний протокол не везде имеет юридическую силу; бесплатные инструменты ограничены по охвату и глубине проверок.
Сколько времени занимает самостоятельный аудит ИБ?

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

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

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

[~DETAIL_TEXT] =>

Можно ли самостоятельно провести ИБ-аудит? Короткий ответ: да, значительную часть аудита информационной безопасности компания может провести сама, и для персональных данных закон это прямо разрешает. Более того, самостоятельная проверка закрывает как раз самый массовый класс проблем. По результатам проверок защищённости, которые Positive Technologies опубликовала в октябре 2026 года, ошибки конфигурации встречались более чем в два раза чаще уязвимостей, подходящие логины и пароли открывали доступ к важным системам в 56% успешных сценариев, а пароли в открытом виде нашлись в 77% проверок. Это не экзотика, которую видно только специализированным инструментом, а то, что администратор способен найти своими руками.

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

Где закон разрешает своими силами, а где нет

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

Опорный случай — персональные данные. Пункт 6 приказа ФСТЭК России № 21 устанавливает, что оценка эффективности реализованных мер по обеспечению безопасности персональных данных проводится оператором самостоятельно или с привлечением на договорной основе организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации, и не реже одного раза в три года. То есть для самого распространённого режима выбор остаётся за оператором.

Режим требований	Кто может проводить	Периодичность
Персональные данные, приказ ФСТЭК № 21	оператор самостоятельно либо лицензиат ТЗКИ	не реже раза в 3 года
Критическая информационная инфраструктура, 187-ФЗ	категорирование проводит внутренняя комиссия субъекта	по правилам постановления № 127
Государственные информационные системы	аттестация — только лицензиат ФСТЭК	при вводе в эксплуатацию и при изменениях
Финансовый сектор, ГОСТ Р 57580	по положениям Банка России, для банков — внешняя проверяющая организация	задаётся положением
ISO 27001 и ГОСТ Р ИСО/МЭК 27001	внутренний аудит обязателен и проводится самой организацией, сертификация — орган по сертификации	внутренний регулярно, сертификационный по циклу
Регуляторных требований нет	любой формат, включая полностью внутренний	по решению компании

Два пояснения к таблице. Для финансовых организаций порядок задают положения Банка России, и там он самый строгий: для банков с 29 марта 2025 года действует Положение № 851-П, заменившее 683-П, для некредитных организаций — Положение № 757-П. Состав допустимых исполнителей оценки и её периодичность нужно смотреть в актуальной редакции своего положения, потому что требования к внешнему исполнителю здесь жёстче, чем в остальных режимах.

По критической инфраструктуре принцип обратный и часто неожидаемый: категорирование объектов субъект КИИ проводит сам, силами собственной комиссии. Правила категорирования менялись, поэтому действующую редакцию постановления № 127 стоит сверить перед началом работ.

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

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

Инвентаризация активов и внешнего периметра

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

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

Ревизия прав доступа и учётных записей

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

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

Решение

Внедрение IdM и PAM-систем

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

Пароли и парольные политики

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

Именно здесь результаты самостоятельной проверки совпадают с тем, что находят профессиональные проверяющие. В исследовании Positive Technologies учётные данные обнаруживались в 96% компаний, а в 77% проверок находились пароли в открытом виде. Поиск по общим папкам и репозиториям на характерные строки — работа на несколько часов, а эффект сопоставим с серьёзным проектом.

Обновления и конфигурации

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

Масштаб проблемы хорошо видно по той же статистике: в 21% проверок использовалась уязвимость, найденная ещё в 2021 году, а в 14% — уязвимость, исправление для которой вышло в 2017-м. Такие находки не требуют пентеста, достаточно сверить версии со списком и посмотреть, где не ставились обновления.

Доступ извне и сегментация

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

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

Устойчивость к фишингу

Почта остаётся основным входом: по данным BI.Zone, которые приводил «Коммерсантъ» в мае 2026 года, с электронной почты начинаются 68% целевых атак. Самостоятельно здесь проверяется техническая часть и организационная.

Техническая: настроены ли SPF, DKIM и DMARC для своих доменных имён, фильтруются ли вложения опасных типов, доходят ли письма с подменённым адресом отправителя от имени своих же руководителей. Последнее проверяется одним тестовым письмом.

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

Резервные копии и журналирование

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

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

Чем это делать

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

Кто внутри компании может провести ИБ-аудит

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

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

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

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

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

Где начинаются границы

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

Независимость

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

В ряде режимов независимость — формальное требование, и тогда вопрос снимается сам. Там, где требования нет, помогает хотя бы разделение внутри компании: проверяет не тот, кто настраивал.

Квалификация в анализе защищённости

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

Показательна статистика векторов из того же исследования: перенаправление чужой попытки входа дало результат в 35% успешных сценариев. Такую атаку не найти ревизией прав или сверкой версий, для неё нужен человек, который умеет её выполнять. И общий результат проверок говорит о том же: в 60% компаний удалось захватить компьютер или сервер, получить доступ к важным данным либо взять под контроль Active Directory, причём в половине случаев на это ушло 13 минут.

Юридическая сила результата

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

Это стоит понимать до начала работ, чтобы не получить ситуацию, когда проверка проведена честно и полно, а предъявить её нечему.

Инструментальный охват

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

Как оформить результат, чтобы он работал

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

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

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

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

Гибридная схема, которая обычно и работает

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

Работа	Кто делает	Периодичность
Ревизия прав и учётных записей	своими силами	раз в квартал
Обновления и неподдерживаемые системы	своими силами	раз в квартал
Контроль резервного копирования с пробным восстановлением	своими силами	раз в квартал
Перечень активов и внешний периметр	своими силами	раз в квартал
Парольная гигиена и поиск паролей в открытом виде	своими силами	раз в квартал
Анализ защищённости и тестирование на проникновение	внешняя организация	раз в год
Независимая оценка архитектуры и процессов	внешняя организация	раз в 2–3 года
Оценка соответствия требованиям	внешняя организация там, где это предписано	по своему режиму
Аттестация и сертификация	лицензиат ФСТЭК или орган по сертификации	по циклу

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

Как подойти к решению

Провести аудит информационной безопасности своими силами можно, и для большинства компаний это правильный первый шаг. Самостоятельно закрываются инвентаризация, ревизия доступов, парольная гигиена, контроль обновлений, резервные копии и журналирование, а по персональным данным оценка эффективности мер прямо разрешена пунктом 6 приказа ФСТЭК № 21. Нельзя сделать самостоятельно три вещи: получить независимое заключение, провести полноценный анализ защищённости и выполнить работы, требующие лицензии, — аттестацию, сертификацию и оценку по требованиям Банка России.

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

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

Решение

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

Проводим независимую проверку с лицензиями ФСТЭК и ФСБ: смотрим то, что внутренняя команда закрыть не может, и отдаём отчёт с находками, приоритетами и планом устранения.

Часто задаваемые вопросы (FAQ)

Можно ли провести аудит информационной безопасности своими силами, без подрядчика?

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

Пункт 6 приказа ФСТЭК России № 21 прямо допускает оба варианта: оценка эффективности реализованных мер по обеспечению безопасности персональных данных проводится оператором самостоятельно либо с привлечением по договору организации, имеющей лицензию на техническую защиту конфиденциальной информации. Периодичность — не реже одного раза в три года. Результат оформляется актом оценки эффективности мер.
Какие проверки дают наибольший результат при самостоятельном аудите?

Ревизия учётных записей и прав, поиск паролей в открытом виде и проверка сетевой достижимости систем управления с обычного рабочего места. По результатам проверок защищённости Positive Technologies за октябрь 2026 года учётные данные находились в 96% компаний, пароли в открытом виде — в 77% проверок, а ошибки конфигурации встречались более чем в два раза чаще уязвимостей. Это тот класс проблем, который виден без пентеста.
Почему внутренняя проверка не заменяет внешнюю?

По четырём причинам: внутренняя команда проверяет собственную работу и не видит ошибок в решениях, которые сама считает верными; анализ защищённости требует отдельной квалификации, и сценарии вроде перенаправления чужой попытки входа (35% успешных векторов у Positive Technologies) ревизией прав не находятся; внутренний протокол не везде имеет юридическую силу; бесплатные инструменты ограничены по охвату и глубине проверок.
Сколько времени занимает самостоятельный аудит ИБ?

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

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

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

Читать

Информационная безопасность

22.09.2026

ИТ-аудит и ИБ-аудит: чем отличаются и когда нужны оба

Array ( [ID] => 3568 [~ID] => 3568 [IBLOCK_ID] => 36 [~IBLOCK_ID] => 36 [IBLOCK_SECTION_ID] => 101 [~IBLOCK_SECTION_ID] => 101 [NAME] => ИТ-аудит и ИБ-аудит: чем отличаются и когда нужны оба [~NAME] => ИТ-аудит и ИБ-аудит: чем отличаются и когда нужны оба [ACTIVE_FROM_X] => 2026-09-22 00:00:00 [~ACTIVE_FROM_X] => 2026-09-22 00:00:00 [ACTIVE_FROM] => 22.09.2026 [~ACTIVE_FROM] => 22.09.2026 [TIMESTAMP_X] => 23.09.2026 17:17:35 [~TIMESTAMP_X] => 23.09.2026 17:17:35 [DETAIL_PAGE_URL] => /blog/it-autsorsing/it-audit-i-ib-audit-chem-otlichayutsya-i-kogda-nuzhny-oba/ [~DETAIL_PAGE_URL] => /blog/it-autsorsing/it-audit-i-ib-audit-chem-otlichayutsya-i-kogda-nuzhny-oba/ [LIST_PAGE_URL] => /blog/ [~LIST_PAGE_URL] => /blog/ [DETAIL_TEXT] =>

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

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

Главное различие — вопрос, на который отвечает аудит

Критерий	ИТ-аудит	Аудит ИБ
Главный вопрос	Работает ли инфраструктура надёжно и эффективно?	Защищена ли она и соответствует ли требованиям?
Что проверяется	Производительность, отказоустойчивость, срок службы оборудования, лицензии, документация	Уязвимости, настройки средств защиты, управление доступами, реагирование на инциденты
Основа оценки	Рекомендации производителей, практика рынка, задачи бизнеса	Модель угроз, требования 152-ФЗ, приказов ФСТЭК, 187-ФЗ, отраслевых стандартов
Результат	Инвентаризация, узкие места, дорожная карта модернизации, обоснование бюджета	Перечень уязвимостей с критичностью, несоответствия требованиям, план устранения
Требования к исполнителю	Опыт в инфраструктуре, специальных лицензий не требуется	Для ряда работ — лицензия ФСТЭК на техническую защиту конфиденциальной информации
Типовые сроки	Экспресс 1–3 дня, комплексный 2–4 недели	2–3 недели для небольшой компании, 1–2 месяца для среднего и крупного бизнеса

Коротко: ИТ-аудитора интересует, не упадёт ли система сама. Аудитора ИБ — не уронит ли её кто-то специально и не утекут ли из неё данные.

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

Где они пересекаются

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

Резервное копирование. ИТ-аудит проверяет, делаются ли копии и удастся ли восстановиться за нужное время. Аудит ИБ — защищены ли сами копии: хранятся ли они изолированно, смогут ли их зашифровать вместе с основными данными при атаке программы-вымогателя.

Учётные записи и доступы. Для ИТ-аудита это вопрос порядка: нет ли лишних учёток, не мешают ли они администрированию. Для аудита ИБ — вопрос риска: кто имеет доступ к критичным данным, отзываются ли права уволенных, нет ли учётных записей с избыточными привилегиями.

Обновления. ИТ-аудит отмечает версии, снятые с поддержки производителем, как риск сбоя и несовместимости. Аудит ИБ — как известные уязвимости, которые можно эксплуатировать.

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

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

Базовую гигиену безопасности ИТ-аудит обычно затрагивает — антивирусная защита, обновления, учёт доступов. Но это проверка на уровне «есть или нет», без оценки того, выдержит ли защита реальную атаку. Заменить аудит ИБ она не может.

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

Когда нужен каждый из них

ИТ-аудит

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

Решение

Аудит ИТ-инфраструктуры

Проведём инвентаризацию, найдём узкие места и риски отказа, подготовим дорожную карту модернизации с приоритетами.

Аудит ИБ

Перед проверкой регулятора или при необходимости подтвердить соответствие 152-ФЗ, приказу ФСТЭК № 117 для государственных систем, 187-ФЗ для субъектов КИИ или ГОСТ Р 57580 для финансовых организаций. После инцидента, чтобы понять, как злоумышленник прошёл и что ещё затронуто. При запуске публичных сервисов с критичными данными. И просто когда в компании обрабатываются персональные данные, а оценки защищённости не было никогда: с 30 мая 2025 года утечка обходится юридическому лицу в 3–15 млн рублей, а повторная — в оборотный штраф.

Когда нужны оба и в каком порядке

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

Типичная ошибка выбора выглядит так. Компания жалуется на медленную работу учётной системы и заказывает аудит безопасности, потому что «вдруг это вирусы». Аудиторы ИБ находят уязвимости, но причину торможения — перегруженное хранилище — не ищут, это не их предмет. Или обратная ситуация: после подозрительной активности заказывают ИТ-аудит и получают отличный отчёт о сроках службы серверов, в котором нет ни слова о том, был ли взлом. Формулировка проблемы определяет вид аудита.

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

Исключение — когда на горизонте проверка регулятора или случился инцидент. Тогда аудит ИБ идёт первым, потому что цена промедления выше.

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

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

С чего начать

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

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

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

Решение

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

Оценим защищённость и соответствие требованиям регуляторов, при необходимости — единым проектом с ИТ-аудитом.

Часто задаваемые вопросы (FAQ)

Чем аудит ИБ отличается от аудита ИТ-инфраструктуры?

Вопросом, на который отвечают. ИТ-аудит оценивает надёжность, производительность, отказоустойчивость и экономику инфраструктуры. Аудит ИБ оценивает защищённость от атак и соответствие требованиям регуляторов: 152-ФЗ, приказов ФСТЭК, 187-ФЗ, отраслевых стандартов. Первый даёт дорожную карту модернизации, второй — перечень уязвимостей и несоответствий с планом устранения.
Может ли ИТ-аудит заменить аудит безопасности?

Нет. ИТ-аудит затрагивает базовую гигиену безопасности — антивирусы, обновления, учёт доступов, — но на уровне «есть или нет». Оценки того, выдержит ли защита реальную атаку и соответствует ли компания требованиям регуляторов, он не даёт.
Какой аудит проводить первым, если нужны оба?

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

Да, если исполнитель выполняет оба вида работ. Сбор данных и интервью проводятся один раз, а на выходе получаются два отчёта с разными выводами. Это экономит время специалистов заказчика, которым иначе пришлось бы дважды отвечать на одни и те же вопросы.
Нужна ли исполнителю лицензия?

Для ИТ-аудита специальных лицензий не требуется. Для работ по аудиту ИБ, связанных с технической защитой конфиденциальной информации, нужна лицензия ФСТЭК России. А оценку соответствия ГОСТ Р 57580 финансовые организации обязаны проводить с привлечением сторонней организации, имеющей такую лицензию.
Сколько времени занимает каждый вид аудита?

Экспресс-обследование ИТ-инфраструктуры занимает один-три дня, комплексный ИТ-аудит — две-четыре недели. Аудит информационной безопасности для небольшой компании проходит за две-три недели, для среднего и крупного бизнеса — за один-два месяца. При проведении обоих единым проектом общий срок меньше суммы.

[~DETAIL_TEXT] =>

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

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

Главное различие — вопрос, на который отвечает аудит

Критерий	ИТ-аудит	Аудит ИБ
Главный вопрос	Работает ли инфраструктура надёжно и эффективно?	Защищена ли она и соответствует ли требованиям?
Что проверяется	Производительность, отказоустойчивость, срок службы оборудования, лицензии, документация	Уязвимости, настройки средств защиты, управление доступами, реагирование на инциденты
Основа оценки	Рекомендации производителей, практика рынка, задачи бизнеса	Модель угроз, требования 152-ФЗ, приказов ФСТЭК, 187-ФЗ, отраслевых стандартов
Результат	Инвентаризация, узкие места, дорожная карта модернизации, обоснование бюджета	Перечень уязвимостей с критичностью, несоответствия требованиям, план устранения
Требования к исполнителю	Опыт в инфраструктуре, специальных лицензий не требуется	Для ряда работ — лицензия ФСТЭК на техническую защиту конфиденциальной информации
Типовые сроки	Экспресс 1–3 дня, комплексный 2–4 недели	2–3 недели для небольшой компании, 1–2 месяца для среднего и крупного бизнеса