Проект

Общее

Профиль

Действия
История

Sidebar »

Практика аудита » История » Редакция 1

Редакция 1/2 | Следующее »
С. Антошкин, 04.06.2026 11:28

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели программы — зачем проводятся аудиты в этом периоде: подтверждение соответствия 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-й стороны Служба ИБ

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

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

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

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

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

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

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

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

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

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

Документ Что ищет аудитор при предварительном анализе
Политика ИБ Дата утверждения, подпись уполномоченного лица, полнота
Область СУИБ Обоснованность границ
SoA(Statement of Applicability) Обоснования исключений, связь с реестром рисков
Реестр рисков Дата последнего обновления, наличие владельцев
Отчёты предыдущих внутренних аудитов Рецидивирующие несоответствия — зоны повышенного внимания
Протоколы анализа со стороны руководства Регулярность, содержание решений
Журналы инцидентов Зарегистрированные инциденты, анализ корневых причин

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

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

Область Основание для приоритизации Глубина проверки
Управление привилегированным доступом Три высоких риска в реестре; MFA не подтверждён в документах Детальная — 100% учётных записей Domain Admins
Управление уязвимостями Несоответствие в предыдущем аудите (патчи не в срок) Расширенная — сканирование + анализ журналов
Резервное копирование Средний риск; предыдущий аудит без замечаний Выборочная — 30% критических систем
Физическая безопасность Низкий риск; стабильно соответствует Минимальная — обход + интервью

Шаг 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 Заключительное совещание Аудиторы + руководство организации

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

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

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

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

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

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

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

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

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

Требование Вопрос для проверки Метод Ожидаемое свидетельство Фактическое свидетельство Вывод
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 дней без зафиксированных причин Незначительное несоответствие — пропуски не задокументированы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Значительное или незначительное несоответствие?
— Это системный отказ процесса или единичное отклонение?
— Блокирует ли это сертификацию или требует корректирующих действий в плановом порядке?
— Создаёт ли это немедленный существенный риск?

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

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

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

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

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

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

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

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

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

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

[[ РИСУНОК: Матрица 2×2: ось X — «Сложность устранения» (низкая / высокая), ось Y — «Уровень риска» (высокий / низкий). Четыре квадранта: «Устранить немедленно» (высокий риск + низкая сложность), «Спланировать проект» (высокий риск + высокая сложность), «Быстрые победы» (низкий риск + низкая сложность), «Включить в план» (низкий риск + высокая сложность). Насыщенные цвета: красный, янтарный, зелёный, серый. ]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Папка 1: Планирование — план аудита, перечень запрошенных документов, предварительный анализ
  • Папка 2: Документальные свидетельства — полученные документы с отметками аудитора
  • Папка 3: Технические свидетельства — скриншоты, выгрузки, отчёты сканирований
  • Папка 4: Интервью — записи интервью с датой, должностью собеседника, ключевыми тезисами
  • Папка 5: Рабочие листы — заполненные чек-листы по каждой области
  • Папка 6: Находки — проект отчёта, матрица несоответствий

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

На практике организации нередко проходят аудит одновременно по нескольким стандартам. Финансовая организация может совмещать 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. Что дальше

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

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

Обновлено С. Антошкин около 9 часа назад · 2 изменени(я, ий)