Главная / База знаний / ISO / Подготовка к сертификационному аудиту ISO 27001: чек-лист для CISO
Главная / База знаний / ISO / Подготовка к сертификационному аудиту ISO 27001: чек-лист для CISO
Сертификационный аудит ISO 27001 — ответственный этап, от которого зависит получение сертификата. В этой статье — полный чек-лист подготовки для CISO: что проверяет аудитор, какие документы обязательны и какие ошибки стоят сертификата.
Сертификационный аудит ISO 27001 — это не просто формальная проверка документов. Это комплексная оценка того, насколько система управления информационной безопасностью (СУИБ) реально работает в организации. По нашему опыту, даже компании с зрелыми процессами ИБ допускают ошибки при подготовке к сертификации — не потому, что их защита слабая, а потому, что они не понимают логику аудитора. Аудитор проверяет не столько техническую защищённость, сколько управляемость системы: есть ли документированные процедуры, ведутся ли записи, проводится ли анализ со стороны руководства.
Роль CISO (Chief Information Security Officer) в подготовке к аудиту — ключевая. Именно он координирует сбор доказательной базы, проверяет полноту документации и организует внутренний аудит. Однако без структурированного подхода даже опытный руководитель ИБ рискует упустить критически важные пункты. Типичная ошибка — сосредоточиться на технических контролях (файрволы, антивирусы, SIEM), забыв о процессных требованиях: внутреннем аудите по ISO 19011, анализе рисков с актуальным реестром, обучении персонала и управлении изменениями.
Структурированный чек-лист решает эту проблему. Он позволяет системно пройти по каждому разделу стандарта ISO/IEC 27001:2022 (пункты 4–10) и каждому применимому контролю Annex A, убедившись, что для каждого требования есть документ, запись или иное свидетельство выполнения. Именно такой чек-лист мы подготовили для вас в этой статье — с разбивкой по категориям и пояснениями, на что аудитор обращает внимание в первую очередь.
Сертификационный аудит ISO 27001 проводится в два этапа, и понимание различий между ними критически важно для правильной подготовки. Многие организации готовятся «ко всему сразу», тогда как на практике каждый этап имеет свои приоритеты, свой фокус и свои типичные ловушки.
Stage 1 — аудит документации (Document Review). На этом этапе аудитор оценивает готовность организации к основному аудиту. Он запрашивает и анализирует ключевые документы СУИБ: область применения (Scope), политику информационной безопасности, методологию оценки рисков, реестр рисков, план обработки рисков, Заявление о применимости (SoA, Statement of Applicability). Аудитор также проверяет, что проведён как минимум один цикл внутреннего аудита и один анализ со стороны руководства (Management Review). Результат Stage 1 — заключение о готовности к Stage 2, а также перечень замечаний, которые необходимо устранить до основного аудита. Между этапами обычно проходит от 2 до 8 недель — используйте это время для устранения всех найденных пробелов.
Stage 2 — сертификационный аудит (Certification Audit). Основной аудит проводится на площадке организации (или удалённо, если это допускается органом по сертификации). Аудитор проверяет, что задокументированные процедуры реально выполняются: интервьюирует сотрудников, запрашивает записи (логи, протоколы, акты), наблюдает за процессами. На аудите проверяют соответствие всем пунктам стандарта (Clauses 4–10) и применимым контролям Annex A. Типичная ошибка — красивые политики, которые существуют только на бумаге. Аудитор быстро выявит это, задав рядовому сотруднику вопрос: «Расскажите, как вы сообщаете об инциденте ИБ?» Если сотрудник не знает процедуры — это свидетельство несоответствия.
| Параметр | Stage 1 | Stage 2 |
|---|---|---|
| Цель | Оценка готовности документации | Проверка реального функционирования СУИБ |
| Формат | Документарная проверка (часто удалённо) | На площадке: интервью, наблюдения, выборки |
| Длительность | 1–2 дня | 3–5 дней (зависит от масштаба) |
| Что проверяют | Scope, политика ИБ, SoA, реестр рисков, план внутреннего аудита | Все контроли Annex A, записи, компетенции персонала, инциденты |
| Результат | Заключение о готовности + замечания | Решение о выдаче/отказе в сертификате |
| Типичная ошибка | Неполный SoA, отсутствие внутреннего аудита | Политики не внедрены, сотрудники не знают процедур |
Практический совет: проведите пробный аудит (mock audit) за 4–6 недель до Stage 1. Это позволит выявить пробелы в документации и устранить их заблаговременно. Подробнее о методологии внутреннего аудита — в нашем материале Внутренний аудит СМК по ISO 19011.
Стандарт ISO/IEC 27001:2022 чётко определяет перечень обязательной документированной информации. Отсутствие любого из этих документов на Stage 1 практически гарантирует замечание, а на Stage 2 — несоответствие (nonconformity). По нашему опыту, около 40% замечаний на первом этапе аудита связаны именно с неполнотой документации, а не с техническими недостатками.
Стандарт различает два типа документированной информации: документы (политики, процедуры, методологии — определяют «как должно быть») и записи (логи, протоколы, акты — подтверждают «как было сделано»). Аудитор проверяет наличие и того, и другого.
Обязательные документы по пунктам стандарта (Clauses 4–10):
Помимо обязательных документов, стандарт подразумевает наличие дополнительных процедур: управления доступом, управления изменениями, резервного копирования, реагирования на инциденты, управления поставщиками. Формально они не являются «обязательными» в тексте стандарта, но аудитор обязательно спросит, как именно реализованы соответствующие контроли Annex A — и без документированной процедуры доказать выполнение будет крайне сложно.
Контроли, связанные с логированием и мониторингом, — одни из самых проверяемых на аудите ISO 27001. Это неудивительно: без качественных логов невозможно ни расследовать инциденты, ни доказать выполнение других контролей. В версии ISO 27001:2022 ключевые требования сосредоточены в контролях A.8.15 (Logging) и A.8.16 (Monitoring Activities).
Контроль A.8.15 — Логирование (Logging). Стандарт требует, чтобы организация определила, какие события подлежат регистрации, обеспечила защиту логов от несанкционированного изменения и удаления, установила сроки хранения и организовала регулярный анализ. На аудите проверяют наличие политики логирования, фактическое ведение журналов событий и их полноту. Типичная ошибка — логи ведутся, но никто их не анализирует. Аудитор запросит свидетельства регулярного анализа: отчёты SIEM, протоколы разбора аномалий, тикеты по результатам мониторинга. Если таких записей нет — контроль считается неэффективным.
Контроль A.8.16 — Мониторинг (Monitoring Activities). Этот контроль расширяет требования к логированию: организация должна не просто собирать логи, а активно отслеживать аномальное поведение в сетях, системах и приложениях. Аудитор ожидает увидеть настроенные правила корреляции в SIEM, пороговые значения для алертов и процедуру реагирования на срабатывания. По нашему опыту, компании средного размера часто имеют SIEM «для галочки»: система установлена, но правила не настроены, алерты не анализируются, а сотрудники SOC перегружены ложными срабатываниями.
Что ещё проверяют из Annex A по теме логирования:
Практическая рекомендация: составьте матрицу логирования — таблицу, в которой для каждого типа системы (серверы, сетевое оборудование, СУБД, приложения, облака) указаны: какие события логируются, где хранятся логи, срок хранения, кто отвечает за анализ, частота проверки. Эта матрица станет ключевым доказательством для аудитора и одновременно рабочим инструментом для вашей команды.
Для кого эта услуга

Для предприятий всех форм собственности

Образовательные центры

Медицинские организации

Предприятия нефтяной, нефтехимической и газовой промышленности

Пищевые предприятия

Строительные и проектные компании
О нашей компании
Постоянно сотрудничаем с крупными государственными и международными корпорациями
Четко выполняем требования контролирующих организаций
Непрерывно работаем над улучшением нашего профессионализма
Послепродажная поддержка в правовых аспектах
Беспроцентная рассрочка (до 4 месяцев)
Бесплатная доставка документации по регионам России лично к заказчику
Клиенты
Благодарственные письма
Управление инцидентами информационной безопасности — один из «горячих» разделов сертификационного аудита ISO 27001. Аудиторы уделяют ему особое внимание, поскольку именно способность организации обнаруживать, реагировать и учиться на инцидентах демонстрирует зрелость СУИБ. В версии ISO 27001:2022 управление инцидентами охватывается контролями A.5.24 (Information Security Incident Management Planning and Preparation), A.5.25 (Assessment and Decision on Information Security Events), A.5.26 (Response to Information Security Incidents) и A.5.27 (Learning from Information Security Incidents).
Что должно быть документировано:
Типичная ошибка — организация заявляет: «У нас не было инцидентов». Для аудитора это красный флаг. Если за 12 месяцев эксплуатации СУИБ не зарегистрировано ни одного события безопасности, это говорит не о совершенной защите, а о неработающем процессе обнаружения. Должны быть хотя бы события, которые были оценены и классифицированы как «не инцидент». Убедитесь, что ваша служба HelpDesk или SOC фиксирует все подозрительные события — даже те, которые в итоге оказались ложными тревогами.
Для организаций, работающих с персональными данными, управление инцидентами пересекается с требованиями 152-ФЗ — подробнее об интеграции этих требований читайте в статье Интеграция ISO 27001 и 152-ФЗ.
Ниже приведён развёрнутый чек-лист подготовки к сертификационному аудиту ISO 27001:2022, сгруппированный по основным категориям. Для каждого пункта указано, какой раздел стандарта или контроль Annex A он покрывает, и что именно аудитор запросит в качестве свидетельства. Используйте этот чек-лист как рабочий инструмент: пройдите по каждому пункту, отметьте статус («готово», «в работе», «отсутствует») и назначьте ответственного за устранение пробелов.
| № | Категория / Пункт проверки | Раздел стандарта | Что запросит аудитор |
|---|---|---|---|
| Документация и управление СУИБ | |||
| 1 | Область применения СУИБ определена и документирована | п. 4.3 | Документ Scope с указанием границ, площадок, процессов |
| 2 | Политика ИБ утверждена руководством и доведена до персонала | п. 5.2 | Подписанная политика, свидетельства ознакомления |
| 3 | Цели ИБ измеримы и актуализированы | п. 6.2 | Документ с целями, метрики, отчёт о достижении |
| 4 | Роли и ответственности в СУИБ назначены | п. 5.3 | Матрица ответственности, приказы о назначении |
| 5 | Процедура управления документированной информацией | п. 7.5 | Процедура, реестр документов, контроль версий |
| Оценка рисков | |||
| 6 | Методология оценки рисков документирована и воспроизводима | п. 6.1.2 | Методология, критерии оценки, шкалы |
| 7 | Реестр рисков актуален (пересмотрен за последние 12 месяцев) | п. 6.1.2, 8.2 | Реестр рисков с датой последнего пересмотра |
| 8 | План обработки рисков связан с контролями Annex A | п. 6.1.3 | План с привязкой к контролям, статус выполнения |
| 9 | SoA содержит обоснование для каждого контроля | п. 6.1.3 d | SoA с 93 контролями, обоснования включения/исключения |
| Логирование и мониторинг | |||
| 10 | Политика логирования определяет типы событий и сроки хранения | A.8.15 | Политика, матрица логирования, настройки SIEM |
| 11 | Логи защищены от модификации и удаления | A.8.15 | Настройки прав доступа к логам, WORM-хранилище |
| 12 | Настроен активный мониторинг аномалий | A.8.16 | Правила корреляции, алерты, отчёты об аномалиях |
| 13 | Часы всех систем синхронизированы (NTP) | A.8.17 | Конфигурация NTP, скриншоты синхронизации |
| Управление инцидентами | |||
| 14 | Процедура реагирования на инциденты документирована | A.5.24, A.5.26 | Процедура с классификацией, ролями, SLA |
| 15 | Журнал инцидентов ведётся и содержит записи | A.5.25 | Журнал с записями, карточки инцидентов |
| 16 | Проведён анализ уроков извлечённых (Lessons Learned) | A.5.27 | Отчёты post-mortem, обновления процедур |
| Управление доступом и персонал | |||
| 17 | Политика управления доступом и процедура предоставления/отзыва прав | A.5.15, A.5.18 | Политика, заявки на доступ, акты пересмотра прав |
| 18 | Пересмотр прав доступа проводится регулярно | A.5.18 | Акты пересмотра с датами, отключённые учётные записи уволенных |
| 19 | Персонал обучен требованиям ИБ и обучение задокументировано | п. 7.2, A.6.3 | Программа обучения, журнал обучения, тесты |
| Поставщики и третьи стороны | |||
| 20 | Реестр поставщиков с оценкой рисков ИБ | A.5.19, A.5.21 | Реестр, договоры с SLA по ИБ, акты проверок |
| 21 | Проводится аудит подрядчиков по информационной безопасности | A.5.22 | Отчёты аудитов поставщиков, чек-листы проверки |
| Внутренний аудит и улучшение | |||
| 22 | Проведён внутренний аудит СУИБ (минимум 1 цикл) | п. 9.2 | Программа аудитов, отчёт, корректирующие действия |
| 23 | Проведён анализ со стороны руководства (Management Review) | п. 9.3 | Протокол совещания, входные данные, решения |
| 24 | Несоответствия из внутреннего аудита закрыты корректирующими действиями | п. 10.2 | Реестр несоответствий, акты корректирующих действий |
| 25 | Метрики эффективности СУИБ определены и собираются | п. 9.1 | Dashboard / отчёт с метриками, тренды |
Этот чек-лист охватывает ключевые области, которые аудитор проверяет на обоих этапах сертификационного аудита. Рекомендуем распечатать его и пройти совместно с командой ИБ не позднее чем за 8 недель до запланированной даты Stage 1. Каждый пункт со статусом «отсутствует» требует немедленного назначения ответственного и срока устранения. Подробнее об аудите поставщиков и третьих сторон — в материале Аудит подрядчиков: информационная безопасность вендоров.
Результатом сертификационного аудита ISO 27001 могут быть три типа выводов: наблюдения (observations) — рекомендации по улучшению, не блокирующие сертификацию; незначительные несоответствия (Minor Nonconformities) — отклонения, которые нужно устранить, но сертификат может быть выдан с условием предоставления плана корректирующих действий; значительные несоответствия (Major Nonconformities) — системные нарушения, блокирующие выдачу сертификата до их устранения и повторной проверки.
Понимание разницы между Major и Minor критически важно для CISO, поскольку одно Major-несоответствие может отложить сертификацию на несколько месяцев и потребовать дополнительного визита аудитора (за дополнительную плату). Minor-несоответствия, как правило, можно закрыть в течение 90 дней после аудита, предоставив свидетельства устранения дистанционно.
| Тип несоответствия | Примеры | Последствия | Как предотвратить |
|---|---|---|---|
| Major | Отсутствует оценка рисков; не проведён внутренний аудит; SoA не содержит обоснований; процесс управления инцидентами полностью отсутствует | Сертификат не выдаётся. Требуется устранение и повторная проверка (follow-up audit) | Пройти все пункты чек-листа; провести полноценный внутренний аудит за 6–8 недель |
| Minor | Политика ИБ не пересмотрена в указанный срок; один пользователь не прошёл обучение; NTP настроен не на всех системах | Сертификат выдаётся с условием: предоставить план корректирующих действий в течение 90 дней | Провести mock-аудит; проверить даты пересмотра документов; выверить списки обученных |
| Observation | Метрики СУИБ можно расширить; процедура обработки рисков слишком общая; рекомендуется автоматизировать процесс пересмотра доступа | Не блокирует сертификацию. Рекомендация к улучшению, проверяется на надзорном аудите | Зафиксировать и включить в план улучшений СУИБ |
По нашему опыту, наиболее частые причины Major-несоответствий — это полное отсутствие обязательных процессов (не «плохо задокументированных», а именно отсутствующих) и системная неспособность продемонстрировать работу цикла PDCA (Plan-Do-Check-Act). Например, если организация провела оценку рисков, но не может показать, что риски пересматривались при изменении обстановки, — это может быть квалифицировано как Major. Аудитор должен видеть, что СУИБ — это живая система, а не набор документов, созданных «для аудита».
Ещё одна распространённая проблема — несогласованность документации. Если в политике указано, что пересмотр прав доступа проводится ежеквартально, а по факту последний пересмотр был 8 месяцев назад, аудитор зафиксирует несоответствие. Лучше указать реалистичную периодичность (раз в полгода) и выполнять её, чем написать «ежемесячно» и не выполнять. Аудитор проверяет не амбициозность политик, а их выполнение.
Получение сертификата ISO 27001 — не финальная точка, а начало трёхлетнего цикла. Сертификат выдаётся на 3 года, и в течение этого периода организация проходит ежегодные надзорные аудиты (surveillance audits), а по истечении срока — аудит ресертификации.
Надзорные аудиты проводятся обычно через 12 и 24 месяца после первоначальной сертификации. Их цель — убедиться, что СУИБ продолжает функционировать, развивается и соответствует стандарту. Надзорный аудит короче сертификационного (1–3 дня), но аудитор проверяет полноценно: внутренние аудиты проведены, Management Review состоялся, инциденты обработаны, корректирующие действия закрыты, метрики собираются. Типичная ошибка — «расслабиться» после получения сертификата. Мы видели случаи, когда компании не проводили внутренний аудит между сертификацией и первым надзорным аудитом — это прямой путь к Major-несоответствию и возможному приостановлению сертификата.
Аудит ресертификации проводится на третий год и по объёму близок к первоначальному сертификационному аудиту. Аудитор оценивает, как СУИБ развивалась за три года: обновлялась ли оценка рисков при изменениях в ИТ-инфраструктуре, актуализировался ли SoA, внедрялись ли новые контроли, учитывались ли уроки из инцидентов.
Что важно помнить CISO для поддержания сертификата:
Если вы планируете расширять область сертификации (например, добавить новые площадки или ИТ-системы), это лучше делать в рамках надзорного аудита. Согласуйте изменения с органом по сертификации заранее — как минимум за 3 месяца. Для IT-компаний, которые задумываются о необходимости сертификата, рекомендуем изучить наш материал Зачем ИТ-компании сертификат ISO 27001.
Подготовка к сертификационному аудиту ISO 27001 — это проект, который требует минимум 3–6 месяцев систематической работы. Ниже — пошаговый план для CISO, основанный на нашем опыте сопровождения десятков сертификаций:
За 6 месяцев до аудита: проведите GAP-анализ текущего состояния СУИБ относительно требований ISO 27001:2022. Определите пробелы в документации и процессах. Составьте план устранения с назначением ответственных и сроков.
За 4 месяца: завершите актуализацию оценки рисков и SoA. Убедитесь, что все применимые контроли Annex A реализованы и для каждого есть документальное подтверждение. Разработайте недостающие процедуры (управление инцидентами, логирование, управление доступом, управление изменениями).
За 2 месяца: проведите полноценный внутренний аудит СУИБ по стандарту ISO 19011. Зафиксируйте все несоответствия и разработайте корректирующие действия. Проведите Management Review с участием высшего руководства.
За 1 месяц: проведите mock-аудит (пробный аудит) силами внешнего консультанта или опытного внутреннего аудитора. Устраните оставшиеся замечания. Подготовьте пакет документов для Stage 1. Проведите awareness-сессию для сотрудников — напомните, что такое СУИБ, как сообщать об инцидентах, какие политики действуют.
За 1 неделю: пройдите по чек-листу из раздела 6 этой статьи. Убедитесь, что для каждого пункта есть актуальное свидетельство. Подготовьте комнату для аудитора, доступ к системам для демонстрации, контактных лиц для интервью.
Подготовка к аудиту ISO 27001 — непростой, но структурированный процесс. При правильном планировании и системном подходе сертификация проходит без Major-несоответствий с первой попытки. Если вам нужна помощь в подготовке к сертификации — специалисты «Астелс» проведут предварительный аудит, помогут разработать недостающую документацию и сопроводят вас на всех этапах — от GAP-анализа до получения сертификата. Свяжитесь с нами для бесплатной консультации.
Была ли полезна вам данная статья?