Проект

Общее

Профиль

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

Sidebar »

Отчёт об аудите и работа с несоответствиями

Введение

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

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

Эта тема завершает практический блок курса. Она опирается на методологию из тем ISO 19011, Объекты и критерии и Практика: программа, план, чек-листы. Три стандарта — ISO 27001, ГОСТ 57580.2 и PCI DSS — используются как наглядные примеры разных подходов к оформлению результатов аудита.

Структура отчёта: общие принципы

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

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

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

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

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

Отчёт по ISO 27001

Структура отчёта о

ISO 27001 не предписывает жёсткий шаблон отчёта о внутреннем аудите — требования к его содержанию вытекают из ISO 19011 и ISO 27007. Типовая структура:

1. Вводная часть
  • Цели аудита и связь с программой аудита
  • Область СУИБ, охваченная данным аудитом (конкретные подразделения, системы, процессы)
  • Применяемые критерии (ISO 27001:2022, конкретные разделы и контролы Приложения А)
  • Состав аудиторской группы и даты проведения
  • Ограничения аудита — что не было проверено и почему
2. Резюме для руководства (1–2 страницы)
  • Общий вывод о соответствии
  • Количество и распределение несоответствий по категориям
  • Три–пять ключевых рисков, выявленных в ходе аудита
  • Динамика по сравнению с предыдущим аудитом
  • Неотложные действия, требующие решения руководства
3. Описание методологии
  • Применённые методы (анализ документов, интервью, технические проверки, наблюдение)
  • Принципы формирования выборки
  • Инструменты технических проверок

4. Детальные результаты по разделам
Для каждого проверенного раздела ISO 27001 (4–10) и каждой группы контролей Приложения А: перечень проверенных требований, методы и свидетельства, вывод (соответствует / несоответствует / не применимо).

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

6. Рекомендации (опционально)
Предложения аудитора по устранению — не обязательные предписания, а профессиональные рекомендации.

Шаблон карточки несоответствия

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

Поле Содержание Пример
Идентификатор Уникальный номер для отслеживания NC-2025-07
Тип Значительное / Незначительное / Наблюдение Значительное несоответствие
Нарушенное требование Конкретный пункт стандарта ISO 27001:2022, контроль 8.5
Формулировка Что нарушено, что обнаружено «Контроль 8.5 требует применения MFA для привилегированного доступа. Проверка 18 учётных записей с правами Domain Admin (выгрузка Azure AD от 15.05.2025, Приложение 3) показала, что MFA не включён для трёх сервисных учётных записей: svc_backup, svc_monitoring, svc_deploy»
Свидетельства Ссылки на рабочие материалы Приложение 3 (скриншот Azure AD), Приложение 7 (интервью с администратором IAM)
Риск Почему это важно Компрометация любой из трёх учётных записей предоставит атакующему права уровня Domain Admin без второго фактора аутентификации
Рекомендация Что конкретно сделать Включить MFA для всех сервисных учётных записей с правами DA; если технически невозможно — задокументировать как компенсирующую меру с обоснованием
Статус Открыто / В работе / Закрыто Открыто
Срок устранения Согласованная дата 30.06.2025

Отчёт по ГОСТ Р 57580.2: количественная оценка соответствия

ГОСТ Р 57580.2 кардинально отличается от ISO 27001 подходом к оформлению результатов: вместо качественного заключения «соответствует / не соответствует» стандарт требует рассчитать числовой показатель соответствия E от 0 до 1 и определить уровень соответствия от нулевого до пятого.

Структура отчёта по ГОСТ 57580.2

1. Общие сведения
Данные о проверяемой организации, составе аудиторской группы, основания для проведения оценки (ссылки на положения ЦБ), период проведения, область оценки.

2. Результаты оценки по каждому процессу
Для каждого из восьми процессов ГОСТ Р 57580.1 — таблица с оценками по каждой мере (0 / 0,5 / 1), промежуточные расчёты по разделам «Система защиты» (Емзи), «Организация и управление» (Емоу), «Жизненный цикл» (Емас), итоговая оценка процесса с учётом PDCA.

3. Сводная таблица оценок

Процесс Планирование (Еп) Реализация (Ер) Контроль (Ек) Совершенствование (Ес) Итог процесса (Епзи)
Процесс 1: Управление доступом 0,92 0,85 0,78 0,60 0,79
Процесс 2: Защита сетей 0,88 0,82 0,75 0,55 0,75
Процесс 3: Целостность и уязвимости 0,90 0,70 0,65 0,40 0,66
Процесс 4: Защита от ВК 0,95 0,90 0,88 0,75 0,87
Процесс 5: Предотвращение утечек 0,80 0,65 0,60 0,35 0,60
Процесс 6: Управление инцидентами 0,85 0,72 0,68 0,45 0,68
Процесс 7: Защита виртуализации 0,90 0,85 0,80 0,65 0,80
Процесс 8: Мобильные устройства 0,88 0,80 0,75 0,55 0,75

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

5. Итоговый показатель соответствия и уровень
Расчёт итогового E с учётом оценок всех процессов, Еас и коэффициента Z. Определение уровня соответствия по шестибалльной шкале стандарта.

6. Выводы и рекомендации
Области с наименьшими показателями (как правило, компонент «Совершенствование» в PDCA — исторически наиболее слабое место), рекомендации по приоритетному повышению оценки.

Ключевая особенность: компонент «Совершенствование»

На практике большинство финансовых организаций имеют существенный разрыв между компонентами PDCA: «Планирование» и «Реализация» получают высокие оценки (меры выбраны и внедрены), а «Контроль» и особенно «Совершенствование» — низкие.

Высокое «Планирование» (0,9) при низком «Совершенствовании» (0,4) — признак того, что организация выполняет требования формально: документы написаны, меры внедрены, но система не учится на ошибках и не улучшается. Именно это различие ГОСТ 57580.2 делает видимым через цикл PDCA в расчёте итоговой оценки.

Отчёт по PCI DSS: ROC и AOC

Структура ROC и AOC детально рассмотрена в теме PCI DSS. Здесь сосредоточимся на специфике оформления находок — как это реализовано в ROC Reporting Template.

Структура карточки тестовой процедуры в ROC

ROC обязывает аудитора-QSA заполнить карточку для каждой из более чем 250 тестовых процедур. Это наиболее детализированный формат из всех рассматриваемых стандартов — каждое требование документируется с максимальной точностью.

Карточка тестовой процедуры 8.4.2 (MFA для всего доступа в CDE):

Требование: 8.4.2 — MFA реализована для всего доступа в CDE.

Тестовые процедуры:
Examine: изучить конфигурации систем аутентификации; изучить политики и процедуры.
Interview: опросить ответственный персонал для подтверждения реализации MFA.
Observe: наблюдать за попыткой входа в системы CDE для подтверждения запроса второго фактора.

Что проверялось:
Examine: конфигурация Azure AD (экспорт 15.05.2025); список 47 учётных записей с доступом в CDE; политика аутентификации v3.1.
Interview: администратор IAM Иванов И.И. (15.05.2025).
Observe: демонстрация входа в систему обработки транзакций.

Результат: Not In Place.

Описание: три из 47 учётных записей (svc_payment_gw, svc_fraud_detection, svc_settlement) имеют прямой доступ в CDE без MFA.

Итоговое заключение ROC

ROC завершается сводным заключением: Compliant (соответствует всем требованиям), Non-Compliant (имеются несоответствия, требующие устранения до подтверждения соответствия) или Compliant with Compensating Controls (соответствует с применением компенсирующих мер).

Компенсирующие меры

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

Что такое компенсирующая мера

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

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

Компенсирующие меры в PCI DSS

PCI DSS наиболее детально регламентирует применение компенсирующих мер. Для каждой компенсирующей меры заполняется CCW со следующими обязательными разделами.

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

Цель: какую цель безопасности преследует исходное требование. Компенсирующая мера должна достигать той же цели.

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

Определение компенсирующей меры: конкретное описание альтернативного контроля.

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

Оценка риска: подтверждение, что компенсирующая мера снижает целевой риск до приемлемого уровня.

Пример CCW для требования об обновлении паролей (8.3.9 PCI DSS): организация использует систему обработки транзакций 1995 года, которая технически не поддерживает пароли длиннее 8 символов. Технический апгрейд запланирован на следующий финансовый год. Компенсирующая мера: обязательный MFA для всех учётных записей в этой системе; мониторинг всех сессий; ручной пересмотр прав каждые 30 дней вместо требуемых 90.

Компенсирующие меры в ГОСТ Р 57580

ГОСТ Р 57580.1 допускает замену меры компенсирующей при двух условиях: техническая невозможность реализации стандартной меры или отсутствие экономической целесообразности. В обоих случаях требуется обоснование в модели угроз и нарушителей.

Логика ГОСТ отличается от PCI DSS: компенсирующая мера не просто заменяет отдельный контроль — она должна нейтрализовывать угрозу, от которой защищала исходная мера. Аудитор проверяет не только факт применения компенсирующей меры, но и её связь с актуальными угрозами из модели.

При заполнении рабочих листов ГОСТ 57580.2 компенсирующая мера обозначается отдельно с соответствующим обоснованием. Она не снижает оценку по мере до нуля, но оценивается по тем же шкалам (0 / 0,5 / 1) в зависимости от полноты реализации.

Компенсирующие меры в ISO 27001

ISO 27001 не использует термин «компенсирующая мера» явно, но предусматривает аналогичный механизм через SoA(Statement of Applicability): организация может исключить контрол из Приложения А, если обоснует это результатами оценки рисков.

При аудите по ISO 27001 аудитор проверяет любое исключение контроля из SoA: задокументировано ли обоснование; связано ли оно с результатами оценки рисков; если контрол заменён альтернативой — достигает ли альтернатива той же цели безопасности.

Сравнение подходов к компенсирующим мерам

Аспект ISO 27001 PCI DSS ГОСТ 57580
Основание для применения Результаты оценки рисков Техническая или операционная невозможность Техническая невозможность или отсутствие экономической целесообразности
Обязательная документация Обоснование в SoA Заполненный Compensating Control Worksheet Обоснование в модели угроз
Кто утверждает Внутренний процесс оценки рисков QSA (аудитор) Аудитор по ГОСТ 57580.2
Влияние на итоговую оценку Не снижает оценку при надлежащем обосновании Отражается в ROC как «Compliant with Compensating Controls» Оценивается по шкале 0/0,5/1
Типичная ошибка Исключение контроля без обоснования риска Ссылка на стоимость как основание Компенсирующая мера не связана с угрозой в модели

Работа с несоответствиями после выпуска отчёта

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

Коррекция и корректирующее действие: принципиальная разница

ISO 9000 и ISO 27001 чётко разграничивают два понятия, которые на практике нередко путают.

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

Корректирующее действие (Corrective Action) — устранение корневой причины, породившей несоответствие. Цель — исключить возможность повторения. Корректирующее действие направлено не на симптом, а на систему: обновить процедуру, изменить конфигурацию шаблона, внедрить автоматическую проверку, провести дополнительное обучение.

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

Пример: при аудите обнаружены три активные учётные записи уволенных сотрудников.

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

Корректирующее действие: проанализировать, почему учётные записи не были заблокированы своевременно → выяснено, что HR не уведомляет IT-службу об увольнениях в день их оформления → внедрить автоматическую интеграцию HR-системы с Active Directory; обновить регламент увольнения с указанием обязательного уведомления IT в день подписания приказа; установить еженедельную автоматическую сверку учётных записей AD с данными HR.

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

Цикл работы с несоответствием: шесть шагов

ISO 27001 (раздел 10.1) и ISO 19011 описывают работу с несоответствием как шестишаговый цикл.

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

Шаг 2: Разработка плана КД. Организация разрабатывает план корректирующих действий для каждого несоответствия. Для значительных несоответствий — в течение согласованного срока (как правило, 30 дней); для незначительных — в плановом порядке.

Каждая строка плана содержит: идентификатор несоответствия, описание коррекции (что уже сделано немедленно), описание корректирующего действия (что устраняет причину), ответственного, срок, критерий завершения.

NC ID Несоответствие Коррекция Корректирующее действие Ответственный Срок Критерий завершения
NC-2025-07 MFA не включён для 3 сервисных DA-аккаунтов Включить MFA для svc_backup, svc_monitoring немедленно; изолировать svc_deploy до разбора Разделить svc_deploy на учётные записи с разными правами; обновить процедуру создания сервисных учётных записей — обязательная проверка MFA перед выпуском в продакшн Руководитель IAM 15.06.2025 Скриншот Azure AD с MFA; обновлённая процедура; записи о проверке всех существующих сервисных учётных записей
NC-2025-12 Журналы резервного копирования — 2 необъяснённых пропуска за 30 дней Провести внеплановую верификацию резервных копий за пропущенные дни Расследовать корневую причину пропусков; внедрить алертинг на пропуски; ввести ежедневную проверку журналов ответственным администратором Администратор ИБ 30.06.2025 Акт расследования с указанием причины; конфигурация алертинга; запись о ежедневных проверках за последние 30 дней

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

«5 Почему» — задавать вопрос «почему?» последовательно до выявления системной причины. Почему MFA не включён для svc_deploy? → Потому что при создании учётной записи не было чек-листа. Почему не было чек-листа? → Потому что процедура создания учётных записей не обновлялась с 2019 года. Почему процедура не обновлялась? → Потому что нет процесса периодического пересмотра документации.

Диаграмма Исикавы (причинно-следственная диаграмма) — применяется для системных несоответствий с несколькими вероятными причинами: люди, процессы, технологии, окружение.

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

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

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

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

Три реакции организации на отчёт

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

«Согласны, устраняем» — конструктивная реакция. Аудитор согласовывает реалистичные сроки и критерии верификации, помогает приоритизировать несоответствия через матрицу рисков (тема 15. Практика).

«Не согласны с формулировкой» — продуктивное несогласие. Организация указывает на фактическую ошибку (аудитор неверно интерпретировал конфигурацию) или неточность формулировки. Аудитор проверяет свидетельства: если организация права — формулировка корректируется; если аудитор прав — несоответствие остаётся с детализированным обоснованием.

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

Отслеживание статуса несоответствий

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

Статус Описание Действие аудитора
Открыто Коррекция не выполнена, план КД не разработан Ожидание плана КД в согласованный срок
Коррекция выполнена Последствия устранены, корректирующее действие в разработке Подтвердить коррекцию, ожидать план КД
В работе План КД разработан, корректирующее действие реализуется Мониторинг соблюдения сроков
Просрочено Срок КД истёк, верификация не проведена Эскалация руководству организации
На верификации Организация заявила об устранении Провести верификацию документально или технически
Закрыто Верификация подтвердила устранение корневой причины Обновить реестр рисков
Принят риск Руководство документально приняло решение о принятии риска Зафиксировать в отчёте, включить в следующий цикл

Несоответствия со статусом «Просрочено» и «Принят риск» автоматически включаются в программу следующего аудита с повышенным приоритетом — это механизм обратной связи между циклами аудита, описанный в теме 9. ISO 19011.

Рецидивирующие несоответствия: системный сигнал

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

Заключительное совещание: как представить результаты

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

Структура заключительного совещания. Цели совещания (не оценка работы персонала, а улучшение системы безопасности). Методология: что и как проверялось, чтобы контекст был понятен. Положительные наблюдения: что работает хорошо — это важно для баланса восприятия. Несоответствия: от значительных к незначительным с бизнес-ориентированным объяснением риска. Следующие шаги: ожидаемые сроки разработки плана КД.

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

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

Специфика отчётности для регуляторов

Отчётность по ГОСТ 57580 для Банка России

Результаты оценки соответствия (итоговый показатель E и уровень соответствия) предоставляются в Банк России в соответствии с требованиями применимого положения ЦБ. Банк России анализирует динамику показателей соответствия по всему рынку и может запросить дополнительные пояснения при существенном снижении показателя.

Отчётность по PCI DSS для платёжных систем

AOC передаётся банку-эквайеру, который хранит его в деле мерчанта. При несоответствии (Non-Compliant) мерчант обязан немедленно уведомить банк-эквайер и разработать план исправления. Платёжная система может запросить ROC напрямую при значительных инцидентах.

Отчётность по требованиям ФСТЭК

Аттестат соответствия является официальным документом, без которого ГИС не может быть введена в эксплуатацию. Несоответствия, выявленные при аттестации, фиксируются в предписании об устранении. ФСТЭК вправе проводить внеплановые проверки выполнения предписания.

Типичные ошибки при составлении отчётов и работе с несоответствиями

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

Что дальше

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

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

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