Аудит / Учебный курс

{{>TOC}}

h1. Практика аудита: программа, план, чек-листы

h2. Введение

Предыдущие темы курса описывали, *что* проверять (стандарты и требования) и *как* собирать свидетельства (методы аудита). Эта тема отвечает на вопрос, который задаёт себе каждый аудитор в начале работы: *с чего начать и как организовать весь процесс?*

Даже опытный аудитор, досконально знающий ISO 27001 и ГОСТ 57580, может провести неэффективный аудит — если не выстроена программа, не составлен реалистичный план и не разработаны инструменты работы со свидетельствами. Практика аудита — это не бюрократия ради бюрократии, а система, которая позволяет получить воспроизводимые, защищаемые и полные результаты.

bq. Эта тема синтезирует методологию из тем [[ISO_19011|ISO 19011]], [[ISO_27007|ISO 27007]], [[Аудит_безопасности_и_методы_его_проведения|Методы проведения аудита]] и [[Оценка_рисков_в_аудите|Риск-ориентированный аудит]] применительно к реальной аудиторской работе. Все примеры построены для типового аудита СУИБ по ISO 27001, но принципы применимы к любому стандарту курса.

---

h2. Программа аудита

*Программа аудита* — стратегический документ, определяющий систему аудитов организации на плановый период (как правило, на год). Это не план конкретного аудита, а расписание и приоритеты для нескольких аудитов.

h3. Зачем нужна программа

Разовый аудит даёт срез состояния на конкретный момент. Программа аудита превращает отдельные проверки в систему управления: позволяет отслеживать динамику, приоритизировать проблемные области, выполнять требования стандартов к периодичности (ISO 27001, раздел 9.2 требует программы внутренних аудитов).

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

h3. Входные данные для программы

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

*Реестр рисков.* Области с высоким остаточным риском проверяются чаще и глубже — это прямое применение риск-ориентированного подхода из темы [[Оценка_рисков_в_аудите|3. Риск-ориентированный аудит]].

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

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

*Требования стандартов.* ISO 27001 требует охвата всей области СУИБ за период сертификационного цикла. PCI DSS требует ежеквартального сканирования ASV и ежегодного пентеста. ГОСТ 57580 устанавливает периодичность оценки. Программа должна обеспечивать выполнение всех этих требований.

*Инциденты ИБ.* Значимый инцидент — основание для внепланового аудита области, где он произошёл.

h3. Структура программы аудита

Типовая программа аудита на год включает следующие разделы.

*Цели программы* — зачем проводятся аудиты в этом периоде: подтверждение соответствия ISO 27001, подготовка к ресертификации, выполнение требований регулятора, проверка устранения несоответствий предыдущего цикла.

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

*Распределение ресурсов* — кто проводит каждый аудит, какая квалификация требуется, нужно ли привлекать внешних аудиторов или технических экспертов.

*Порядок управления программой* — как актуализируется программа, кто её утверждает, как фиксируются отклонения.

|_.Аудит|_.Область|_.Критерии|_.Квартал|_.Тип|_.Исполнитель|

|Аудит управления доступом|Все системы в области СУИБ|ISO 27001, контролы 8.2–8.5|Q1|Внутренний|Служба ИБ (независимый отдел)|

|Аудит управления уязвимостями|CDE + корпоративная сеть|PCI DSS треб. 11, ISO 27001 контроль 8.8|Q1, Q2, Q3, Q4|Технический (ASV)|Внешний ASV|

|Аудит резервного копирования|Критические системы|ISO 27001 контроль 8.13, ГОСТ 57580 ЦЗИ|Q2|Внутренний|IT-аудит|

|Комплексный аудит СУИБ|Вся область ISO 27001|ISO 27001, разделы 4–10 + Приложение А|Q3|Внутренний|Руководитель ИБ + внешний эксперт|

|Пентест|Периметр CDE + внутренняя сеть|PCI DSS треб. 11.4|Q3|Технический|Внешняя QSA|

|Аудит поставщиков|Три ключевых поставщика|ISO 27001 контроль 5.19, договорные требования|Q4|Аудит 2-й стороны|Служба ИБ|

---

h2. Подготовка конкретного аудита

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

h3. Шаг 1: Уточнение области, критериев и целей

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

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

*Какие критерии применяются?* Конкретные разделы и пункты стандарта, версия стандарта, применимые национальные нормы. Если аудит совмещает несколько критериев (например, ISO 27001 и ГОСТ 57580), составляется матрица соответствия, исключающая дублирование.

*Каковы цели аудита?* Подтверждение соответствия для сертификации, проверка устранения несоответствий, оценка конкретного риска, подготовка данных для регулятора.

h3. Шаг 2: Предварительный анализ документации

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

Типовой перечень документов для предварительного анализа при аудите ISO 27001:

|_.Документ|_.Что ищет аудитор при предварительном анализе|

|Политика ИБ|Дата утверждения, подпись уполномоченного лица, полнота|

|Область СУИБ|Обоснованность границ|

|SoA(Statement of Applicability)|Обоснования исключений, связь с реестром рисков|

|Реестр рисков|Дата последнего обновления, наличие владельцев|

|Отчёты предыдущих внутренних аудитов|Рецидивирующие несоответствия — зоны повышенного внимания|

|Протоколы анализа со стороны руководства|Регулярность, содержание решений|

|Журналы инцидентов|Зарегистрированные инциденты, анализ корневых причин|

h3. Шаг 3: Риск-ориентированное планирование выборки

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

|_.Область|_.Основание для приоритизации|_.Глубина проверки|

|Управление привилегированным доступом|Три высоких риска в реестре; MFA не подтверждён в документах|Детальная — 100% учётных записей Domain Admins|

|Управление уязвимостями|Несоответствие в предыдущем аудите (патчи не в срок)|Расширенная — сканирование + анализ журналов|

|Резервное копирование|Средний риск; предыдущий аудит без замечаний|Выборочная — 30% критических систем|

|Физическая безопасность|Низкий риск; стабильно соответствует|Минимальная — обход + интервью|

h3. Шаг 4: Составление плана аудита

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

Обязательные элементы плана:

* цели и область аудита (подтверждение из программы);

* применяемые критерии (стандарт, версия, конкретные разделы);

* состав аудиторской группы и распределение обязанностей;

* расписание по дням — кто, что, когда и где проверяет;

* список интервьюируемых лиц (должность, не имя) и тематика интервью;

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

* логистика — место проведения, доступ к помещениям и системам;

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

Пример расписания трёхдневного аудита СУИБ:

|_.День|_.Время|_.Активность|_.Участники|

|День 1|09:00–10:00|Вводное совещание|Аудиторы + руководство организации|

|День 1|10:00–12:00|Анализ документации: политики, область, SoA, реестр рисков|Аудитор 1|

|День 1|13:00–15:00|Интервью: директор по ИБ, руководитель IT|Аудитор 1|

|День 1|13:00–17:00|Технические проверки: выгрузка AD, анализ прав доступа|Аудитор 2 + технический эксперт|

|День 2|09:00–12:00|Интервью: владельцы бизнес-процессов (3 подразделения)|Аудитор 1|

|День 2|09:00–12:00|Технические проверки: сканирование, анализ конфигураций МЭ|Аудитор 2 + технический эксперт|

|День 2|13:00–15:00|Интервью: IT-администраторы, рядовые сотрудники (выборка)|Аудитор 1|

|День 2|13:00–17:00|Анализ журналов SIEM, проверка резервного копирования|Аудитор 2|

|День 3|09:00–12:00|Обход объекта: серверная, рабочие места, переговорные|Оба аудитора|

|День 3|13:00–15:00|Анализ и согласование находок внутри группы|Аудиторская группа|

|День 3|15:00–17:00|Заключительное совещание|Аудиторы + руководство организации|

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

---

h2. Разработка чек-листов и рабочих листов

Чек-лист и рабочий лист — рабочие инструменты аудитора. Без них аудит превращается в неструктурированное хождение по организации с субъективными выводами.

h3. Чек-лист vs. рабочий лист: в чём разница

*Чек-лист* — список требований (контролей, пунктов стандарта) для проверки. Отвечает на вопрос «что проверить». Используется для планирования охвата и контроля полноты.

*Рабочий лист* — инструмент сбора свидетельств. Для каждого требования из чек-листа фиксируются вопросы, ожидаемые свидетельства, фактические свидетельства и вывод. Отвечает на вопросы «как проверить» и «что обнаружено».

На практике эти два инструмента нередко объединяют в один документ.

h3. Структура рабочего листа

Типовая структура рабочего листа — шесть колонок.

|_.Требование|_.Вопрос для проверки|_.Метод|_.Ожидаемое свидетельство|_.Фактическое свидетельство|_.Вывод|

|ISO 27001, контроль 8.5|Реализован ли MFA для всех привилегированных учётных записей?|Examine + Interview|Конфигурация AD с включённым MFA; список DA; интервью с администратором|Скриншот Azure AD: MFA включён для 15 из 18 учётных записей DA; три сервисные учётные записи без MFA (Приложение 3)|*Значительное несоответствие* — MFA отсутствует для 3 сервисных DA-аккаунтов|

|ISO 27001, контроль 8.13|Соответствует ли расписание резервного копирования установленному RPO?|Examine|Задание в системе резервного копирования; журнал выполнения за 30 дней|Задание настроено на ежедневный запуск; журнал показывает 2 пропуска за 30 дней без зафиксированных причин|*Незначительное несоответствие* — пропуски не задокументированы|

h3. Принципы разработки чек-листов

*Привязка к конкретному пункту стандарта.* Каждый пункт чек-листа ссылается на конкретное требование с номером раздела и пунктом. Без привязки невозможно сформулировать несоответствие.

*Один пункт — одно требование.* Объединение нескольких требований в один пункт («проверить управление доступом») ведёт к поверхностным выводам. Каждый контроль — отдельная строка.

*Формулировка в виде проверяемого утверждения.* Не «управление паролями», а «минимальная длина пароля составляет не менее 12 символов для всех учётных записей (требование 8.3.6 PCI DSS)».

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

*Масштабируемость.* Чек-лист для внутреннего аудита одного контроля занимает одну страницу. Чек-лист для полного аудита ISO 27001 — сотни пунктов. Структура должна быть одинаковой, чтобы результаты разных аудитов можно было сравнивать.

h3. Типы чек-листов для разных стандартов

*Для аудита ISO 27001* чек-лист структурируется по разделам стандарта (4–10) и по группам контролей Приложения А. Для каждого раздела отдельный лист — это упрощает распределение между несколькими аудиторами.

*Для аудита PCI DSS* структура чек-листа следует 12 требованиям стандарта с детализацией по тестовым процедурам из ROC Reporting Template. Для каждой тестовой процедуры фиксируется метод (Examine/Interview/Observe).

*Для аудита ГОСТ Р 57580* чек-лист строится по восьми процессам с отдельными листами для разделов «Система защиты», «Организация и управление», «Жизненный цикл». Для каждой меры — признак применимости (Н/О/Т) и шкала оценки (0/1).

*Для аудита по требованиям ФСТЭК* чек-лист строится по группам мер (ИАФ, УПД, АНЗ, РСБ и т.д.) с привязкой к классу/уровню/категории системы.

h3. Пример фрагмента чек-листа для аудита управления доступом

{{collapse(Чек-лист: управление привилегированным доступом (ISO 27001 + ГОСТ 57580))

|_.№|_.Требование|_.Вопрос|_.Метод|_.Ожидаемое свидетельство|_.Свидетельство факт.|_.Оценка|

|1.1|ISO 27001, 8.2 — Привилегированные права доступа|Задокументирован ли перечень привилегированных учётных записей и обоснование их наличия?|Examine|Актуальный перечень, утверждённый владельцем системы| | |

|1.2|ISO 27001, 8.5 — Безопасная аутентификация|Включён ли MFA для всех привилегированных учётных записей, включая сервисные?|Examine + Observe|Конфигурация AD; список учётных записей с признаком MFA| | |

|1.3|ГОСТ 57580.1, РД.12|Исключена ли возможность открытия параллельных сессий под одной учётной записью с разных АРМ?|Examine + Observe|Конфигурация системы; практическая демонстрация| | |

|1.4|ISO 27001, 8.2|Пересматриваются ли привилегированные права не реже чем раз в квартал?|Examine + Interview|Журнал пересмотров прав; интервью с администратором| | |

|1.5|ГОСТ 57580.1, УЗП|Заблокированы ли учётные записи уволенных сотрудников?|Examine|Список учётных записей AD; данные HR об уволенных за последние 6 месяцев| | |

}}

---

h2. Анализ свидетельств и формулирование выводов

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

h3. Проверка достаточности и надлежащего характера

Перед формулированием вывода аудитор задаёт себе два вопроса из ISO 19011.

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

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

h3. Триангуляция

Принцип триангуляции (рассмотренный в теме [[ISO_19011|ISO 19011]]) применяется на этапе анализа: для каждого значимого вывода аудитор стремится к подтверждению из двух-трёх независимых источников разного типа. Противоречие между источниками — сигнал для углублённой проверки.

h3. Классификация находок

По итогам анализа свидетельств каждая находка классифицируется. Критерии классификации рассмотрены в теме [[Объекты_и_критерии_аудита|Объекты и критерии]], здесь — практическое применение.

Вопросы, которые помогают классифицировать находку:

*Значительное или незначительное несоответствие?*

— Это системный отказ процесса или единичное отклонение?

— Блокирует ли это сертификацию или требует корректирующих действий в плановом порядке?

— Создаёт ли это немедленный существенный риск?

Если ответ «да» хотя бы на один вопрос — значительное несоответствие.

*Несоответствие или наблюдение?*

— Нарушено ли конкретное требование стандарта?

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

h3. Формулировка несоответствия

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

Обязательные элементы формулировки: *что нарушено* (ссылка на конкретное требование), *что обнаружено* (фактическое состояние), *на чём основан вывод* (ссылка на свидетельство).

Пример слабой формулировки: «Управление уязвимостями не соответствует требованиям».

Пример сильной формулировки: «Согласно контролю 8.8 ISO 27001:2022, организация должна своевременно устранять технические уязвимости. Сканирование уязвимостей от 10.05.2025 (Приложение 5) выявило 7 критических уязвимостей (CVSS ≥ 9.0) на серверах в области СУИБ, из которых 5 существуют более 90 дней. Внутренняя политика управления уязвимостями (версия 2.1, раздел 4.3) требует устранения критических уязвимостей в течение 30 дней. Несоответствие подтверждено выгрузкой из системы управления уязвимостями и интервью с администратором ИБ (10.05.2025)».

h3. Матрица приоритизации находок

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

!clipboard-202606041429-l2n8r.png!

h3. Анализ противоречий между свидетельствами

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

*Документ соответствует требованиям, техническая проверка показывает несоответствие.* Наиболее распространённый случай: политика паролей требует 12 символов, групповая политика AD настроена на 8. Вывод — несоответствие: документ отражает намерение, техническая конфигурация — реальность.

*Технические данные соответствуют, интервью показывает непонимание.* Конфигурация MFA корректна, но администратор не знает, для каких учётных записей она применяется. Потенциальное несоответствие раздела 7.2 (компетентность) или 7.3 (осведомлённость).

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

---

h2. Документирование рабочих материалов аудита

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

h3. Требования к рабочим материалам

*Идентификация каждого свидетельства.* Источник (система, документ, имя интервьюируемого), дата и время получения, метод получения, кем получено.

*Привязка к выводу.* Каждое свидетельство связано с конкретным пунктом чек-листа и выводом. Свидетельство без привязки к выводу бесполезно для защиты результатов аудита.

*Защита конфиденциальности.* Рабочие материалы содержат детальную информацию об инфраструктуре и уязвимостях — они должны храниться и передаваться только через защищённые каналы.

*Срок хранения.* Как правило, рабочие материалы хранятся не менее трёх лет — достаточно для покрытия одного сертификационного цикла ISO 27001 и для разрешения возможных споров.

h3. Структура папки рабочих материалов

Типовая структура рабочей папки аудита:

* Папка 1: Планирование — план аудита, перечень запрошенных документов, предварительный анализ

* Папка 2: Документальные свидетельства — полученные документы с отметками аудитора

* Папка 3: Технические свидетельства — скриншоты, выгрузки, отчёты сканирований

* Папка 4: Интервью — записи интервью с датой, должностью собеседника, ключевыми тезисами

* Папка 5: Рабочие листы — заполненные чек-листы по каждой области

* Папка 6: Находки — проект отчёта, матрица несоответствий

---

h2. Совмещённый аудит: работа с несколькими стандартами

На практике организации нередко проходят аудит одновременно по нескольким стандартам. Финансовая организация может совмещать ISO 27001, ГОСТ 57580 и требования ФСТЭК. Банк-эквайер — ISO 27001 и PCI DSS.

Ключевой инструмент совмещённого аудита — *матрица соответствия требований* (crosswalk matrix): таблица, показывающая, какие требования разных стандартов покрываются одним и тем же свидетельством.

|_.Область проверки|_.ISO 27001|_.PCI DSS v4.0|_.ГОСТ 57580.1|_.Одно свидетельство покрывает|

|Управление привилегированным доступом|8.2, 8.5|Треб. 7, 8.4|УЗП, РД.12|Выгрузка прав из AD + конфигурация MFA|

|Управление уязвимостями|8.8|Треб. 11.3|АНЗ|Отчёт сканера уязвимостей|

|Журналирование событий|8.15, 8.16|Треб. 10|РИ|Конфигурация SIEM + образцы журналов|

|Резервное копирование|8.13|Треб. 12.10.1|ЦЗИ|Конфигурация резервного копирования + журнал верификации|

Матрица соответствия составляется на этапе подготовки и позволяет сократить объём работ до 30–40% по сравнению с двумя независимыми аудитами.

---

h2. Что дальше

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

* *Следующая тема:* [[Отчетная_документация|Отчёт об аудите и работа с несоответствиями]] — структура отчёта, формулировки, корректирующие действия

* *Методологическая основа:* [[ISO_19011|ISO 19011]] — процессная модель, на которой построена эта тема

* *Риск-ориентированное планирование:* [[Оценка_рисков_в_аудите|Риск-ориентированный аудит]] — реестр рисков как входной документ для программы аудита

---

h2. Список литературы

* "ISO 19011:2018":https://www.iso.org/standard/70017.html — разделы 5 (программа аудита) и 6 (проведение аудита)

* "ISO/IEC 27007:2021":https://www.iso.org/standard/77802.html — руководство по аудиту СУИБ, включая рабочие документы

* "ISACA IS Audit and Assurance Guideline 2201":https://www.isaca.org/resources — Engagement Planning

* "ISACA IS Audit and Assurance Guideline 2205":https://www.isaca.org/resources — Evidence

* "PCI DSS v4.0.1 ROC Reporting Template":https://www.pcisecuritystandards.org/document_library/ — образец структуры рабочих листов для PCI DSS

* "NIST SP 800-53A Rev.5":https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final — методология оценки контролей (Examine / Interview / Test)

* Champlain J. — Auditing Information Systems. 2nd ed. Wiley, 2003