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

{{>TOC}}

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

h2. Введение

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

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

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

---

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

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

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

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

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

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

---

h2. Отчёт по ISO 27001

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

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

*1. Вводная часть*

* Цели аудита и связь с программой аудита

* Область СУИБ, охваченная данным аудитом (конкретные подразделения, системы, процессы)

* Применяемые критерии (ISO 27001:2022, конкретные разделы и контролы Приложения А)

* Состав аудиторской группы и даты проведения

* Ограничения аудита — что не было проверено и почему

*2. Резюме для руководства* (1–2 страницы)

* Общий вывод о соответствии

* Количество и распределение несоответствий по категориям

* Три–пять ключевых рисков, выявленных в ходе аудита

* Динамика по сравнению с предыдущим аудитом

* Неотложные действия, требующие решения руководства

*3. Описание методологии*

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

* Принципы формирования выборки

* Инструменты технических проверок

*4. Детальные результаты по разделам*

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

*5. Перечень находок*

Все несоответствия и наблюдения, оформленные по единому шаблону.

*6. Рекомендации* (опционально)

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

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

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

|_.Поле|_.Содержание|_.Пример|

|*Идентификатор*|Уникальный номер для отслеживания|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|

---

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

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

h3. Структура отчёта по ГОСТ 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 — исторически наиболее слабое место), рекомендации по приоритетному повышению оценки.

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

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

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

---

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

Структура ROC(Report on Compliance) и AOC(Attestation of Compliance) детально рассмотрена в теме [[PCI_DSS|PCI DSS]]. Здесь сосредоточимся на специфике оформления находок — как это реализовано в ROC Reporting Template.

h3. Структура карточки тестовой процедуры в 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.

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|_.Аспект|_.ISO 27001|_.PCI DSS|_.ГОСТ 57580|

|Основание для применения|Результаты оценки рисков|Техническая или операционная невозможность|Техническая невозможность или отсутствие экономической целесообразности|

|Обязательная документация|Обоснование в SoA|Заполненный Compensating Control Worksheet|Обоснование в модели угроз|

|Кто утверждает|Внутренний процесс оценки рисков|QSA (аудитор)|Аудитор по ГОСТ 57580.2|

|Влияние на итоговую оценку|Не снижает оценку при надлежащем обосновании|Отражается в ROC как «Compliant with Compensating Controls»|Оценивается по шкале 0/0,5/1|

|Типичная ошибка|Исключение контроля без обоснования риска|Ссылка на стоимость как основание|Компенсирующая мера не связана с угрозой в модели|

---

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

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

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

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

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

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

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

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

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

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

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

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

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: Верификация эффективности.* Аудитор проверяет, что корректирующее действие действительно устранило несоответствие и не породило новых проблем. Верификация может быть документальной или технической.

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

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

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

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

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

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

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

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

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

|_.Статус|_.Описание|_.Действие аудитора|

|Открыто|Коррекция не выполнена, план КД не разработан|Ожидание плана КД в согласованный срок|

|Коррекция выполнена|Последствия устранены, корректирующее действие в разработке|Подтвердить коррекцию, ожидать план КД|

|В работе|План КД разработан, корректирующее действие реализуется|Мониторинг соблюдения сроков|

|Просрочено|Срок КД истёк, верификация не проведена|Эскалация руководству организации|

|На верификации|Организация заявила об устранении|Провести верификацию документально или технически|

|Закрыто|Верификация подтвердила устранение корневой причины|Обновить реестр рисков|

|Принят риск|Руководство документально приняло решение о принятии риска|Зафиксировать в отчёте, включить в следующий цикл|

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

|_.Ошибка|_.Последствие|

|Резюме для руководства написано техническим языком|Руководство не понимает рисков и не принимает управленческих решений|

|Несоответствия сформулированы без ссылки на конкретное требование|Организация оспаривает вывод; невозможно проверить устранение|

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

|Компенсирующие меры приняты без проверки их связи с целью контроля|Компенсирующая мера не закрывает целевой риск; соответствие формально, риск реален|

|Верификация устранения проводится только документально|Симптом устранён, системная проблема осталась|

|Корневая причина несоответствия не анализируется|Рецидив несоответствия в следующем цикле аудита|

|Принятие риска не фиксируется документально|Аудитор не может доказать, что организация была уведомлена о риске|

|Отчёт рассылается по обычной электронной почте|Детальная карта уязвимостей попадает в незащищённый канал|

---

h2. Что дальше

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

* *Следующая тема:* [[Непрерывный_мониторинг|Непрерывный мониторинг соответствия]] — автоматизация контроля, метрики, интеграция с SIEM

* *Практика аудита:* [[Практика_аудита|Практика: программа, план, чек-листы]] — как рабочие листы становятся основой отчёта

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

---

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

* "ISO 19011:2018":https://www.iso.org/standard/70017.html — раздел 6.6: подготовка и рассылка отчёта по аудиту

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

* ГОСТ Р 57580.2-2018 — раздел 7: оформление результатов оценки соответствия

* "PCI DSS v4.0 ROC Reporting Template":https://www.pcisecuritystandards.org/document_library/ — официальный шаблон отчёта QSA

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

* "ISACA IS Audit and Assurance Guideline 2402":https://www.isaca.org/resources — Follow-up Activities

* Champlain J. — Auditing Information Systems. 2nd ed. Wiley, 2003 — глава 9: Reporting Audit Results