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

Я провёл двадцать лет в кибербезопасности, и значительная часть этого времени ушла на аудиты: подготовку к ним, участие в них, споры о выводах и исправление того, что они выявили. Стандарты за это время менялись много раз. Эти уроки — нет.
1. Доказательства важнее рассказа
Самое распространённое замечание аудита — не отсутствующий контроль. Это контроль, который был выполнен, но его нельзя подтвердить. Проверка доступа состоялась, но никто не сохранил список. Изменение было одобрено в чате, который с тех пор удалили. Аудиторы могут опираться только на то, что видят. Выстраивайте средства контроля так, чтобы доказательства появлялись побочно, в процессе их выполнения, и большинство замечаний исчезнет.
2. Область определяет всё
Большинство проблем с аудитом сводятся к области охвата: её провели слишком широко, так что каждая система должна соответствовать каждому контролю; или слишком узко, так что сертификат не отвечает на вопрос клиента; или расплывчато, так что никто не знает, какие системы считаются. Определите её осознанно, зафиксируйте письменно и обоснуйте. Наша статья о определении области первого отчёта SOC 2 применима почти к любому аудиту.
3. Не работают те средства контроля, у которых нет владельца
Когда у средства контроля есть назначенный владелец, который выполняет его в рамках своих обязанностей, оно работает. Когда оно принадлежит «ИТ» или «службе безопасности» в целом, оно дрейфует до самой недели перед аудитом. Назначение владельца — самое дешёвое улучшение контроля из всех возможных.

4. Документы должны описывать реальность
Типовые политики, которые описывают компанию, которой вы не являетесь, хуже коротких, которые описывают ту компанию, которой вы являетесь. Аудиторы проверяют то, что вы написали. Каждый разрыв между документом и практикой становится замечанием, а часто — проблемой доверия ко всему остальному, что вы им показываете.
5. Аудиторы полезнее как союзники, чем как противники
Лучше всего проходят те аудиты, в которых команда относится к аудитору как ко второй паре глаз, а не как к оппоненту. Спросите заранее, как они будут проверять средство контроля. Заявляйте о известных слабостях вместе с планом. Замечание, которое вы подняли сами, с уже запущенным исправлением, воспринимается совсем иначе, чем то, которое им пришлось откапывать.
6. Второй стандарт должен обходиться дёшево
Организации, которые ведут отдельную программу под каждый стандарт, оплачивают каждый аудит полностью. Те, что строят один набор средств контроля, сопоставленный со всеми стандартами, которым они обязаны отвечать, платят в основном один раз. Работа по сопоставлению скучна, но её эффект накапливается. Это во многом и есть причина, по которой я создал ControlMapping.
7. Разные стандарты, одни и те же вопросы
После достаточного количества аудитов стандарты начинают сливаться. Аудиторы ISO, аудиторы SOC 2, оценщики PCI и регуляторы используют разные слова, но задают одни и те же несколько вопросов: что входит в область, кто отвечает, откуда вы знаете, что это работает, и что происходит, когда не работает? Организация, которая может ясно ответить на эти четыре вопроса, подкрепив ответы доказательствами, хорошо проходит почти любой аудит. Матрица покрытия хорошо это иллюстрирует: по одиннадцати стандартам одни и те же основные темы повторяются снова и снова.
Ключевые выводы
- Выстраивайте средства контроля так, чтобы доказательства появлялись как побочный результат.
- Определяйте область осознанно и назначайте каждому средству контроля владельца.
- Относитесь к аудитам как к побочному продукту хорошо налаженной безопасности.
8. Прохождение — не цель
Чистый аудит означает, что средства контроля в области работали на проверенных выборках. Это не значит, что организация защищена; соответствие требованиям — не безопасность. Лучшие команды, с которыми я работал, рассматривают аудиты как побочный продукт хорошо налаженной безопасности, а не как её цель.
Если запомнить одно: решите, что вы делаете, делайте это последовательно, и пусть доказательства накапливаются сами. Анализ разрывов — хорошее место, чтобы увидеть, насколько далеко ваши текущие средства контроля уже простираются.
Вопросы
Какова самая распространённая причина замечаний по итогам аудита?
По моему опыту, это отсутствующие или неполные доказательства для средств контроля, которые действительно выполнялись: проверки проведены, но не зафиксированы, изменения одобрены устно, наборы данных не совпадают с выгрузкой.
Как готовиться к аудиту безопасности?
Выполняйте средства контроля непрерывно и фиксируйте их доказательства по ходу дела, проверяйте, что документы соответствуют практике, и пройдите выборку самостоятельно до того, как это сделает аудитор.
Стоит ли сообщать аудитору о известных нам слабых местах?
Как правило, да. Слабое место, которое вы выявили, с назначенным владельцем и планом устранения, воспринимается как работающая среда контроля. Если его обнаруживает аудитор, это воспринимается как пробел в надзоре.
Данные на 2026-10-27: цифры в этой публикации рассчитаны по текущей таблице соответствий и обновляются при её изменении. Соответствия связь установлена опубликованной таблицей соответствий (NIST, ENISA, CIS, PCI SSC) · Редакционные материалы Суждение ControlMapping там, где таблицы соответствий не существует; причина указана · есть только общий результат CSF 2.0: стоит проверить, но это не сопоставление · Нет сопоставления в наших данных в наших данных ничего не сопоставлено; часто это новая работа, но проверьте примечания о покрытии. Не является консультацией по соответствию.