Что проверить перед ISO 27001: чеклист старта

Пост обновлен 23.05.2026
Автор статьи: Daniyar Abdi | LinkedIn

Главная страница ➡️ Технологии ➡️ Что проверить перед ISO 27001

9-14 минут

Что проверить перед ISO 27001 — вопрос, который лучше задать до старта проекта, а не перед аудитом. ISO 27001 часто воспринимают как набор документов для сертификации. На практике это система управления информационной безопасностью: область действия, риски, активы, роли, процессы, контроль доступа, инциденты, поставщики, обучение, внутренний аудит и решения руководства.

Если компания начинает ISO 27001 без подготовки, проект быстро застревает. Команда не понимает границы сертификации, владельцы процессов не назначены, активы не описаны, риски оцениваются формально, документы пишутся отдельно от реальной работы. В редакционном подходе Stilo.kz ISO 27001 стоит начинать не с шаблонов политик, а с проверки готовности бизнеса управлять безопасностью системно.

Содержание

Что проверить перед ISO 27001 в первую очередь?

Перед ISO 27001 нужно проверить область действия, цели проекта, поддержку руководства, список активов, владельцев процессов, текущие риски, документы, доступы, поставщиков, инциденты, внутренние ресурсы и бюджет на внедрение.

Главные вопросы перед стартом:

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

Если на эти вопросы нет ответов, проект лучше не запускать «в полный рост». Сначала нужно провести readiness assessment — предварительную проверку готовности.

Почему ISO 27001 застревает еще до аудита?

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

Типичные причины задержек:

область действия выбрана слишком широко;
руководство формально поддерживает проект, но не участвует;
нет ответственного за ISMS;
IT, HR, юристы и бизнес работают отдельно;
активы не описаны;
доступы не ревизуются;
поставщики не проверяются;
инциденты не фиксируются;
риски оценивают «для галочки»;
документы не соответствуют реальной практике;
внутренний аудит оставляют на последний момент;
корректирующие действия не закрываются.

ISO 27001 требует не идеальной безопасности, а управляемой системы. Если компания не может показать, как она принимает решения по рискам и улучшениям, аудитору будет сложно увидеть работающую ISMS.

Как определить область действия ISO 27001?

Область действия — это границы системы управления информационной безопасностью. Она отвечает на вопрос: что именно компания сертифицирует. Это может быть вся организация, отдельный продукт, дата-центр, SaaS-сервис, подразделение, офис, процесс разработки или конкретная услуга.

Перед стартом проверьте:

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

Слишком широкая область усложняет проект. Слишком узкая может не покрыть ожидания клиентов. Например, если клиент ожидает сертификацию всего SaaS-продукта, а компания сертифицирует только офисную IT-инфраструктуру, сертификат может не решить бизнес-задачу.

Что проверить в активах и данных?

Информационные активы — это не только серверы и ноутбуки. Это данные клиентов, базы, код, учетные записи, договоры, документация, конфигурации, резервные копии, ключи доступа, CRM, облачные сервисы и знания сотрудников.

Что проверить	Зачем это нужно	Частая проблема
Реестр активов	Понять, что защищать	Активы есть, но никто не владелец
Классификацию данных	Разделить критичное и обычное	Все данные считают одинаковыми
Владельцев активов	Назначить ответственность	Все отвечает IT, но решения принимает бизнес
Места хранения	Понять, где находятся данные	Часть данных в личных облаках и таблицах
Доступы	Проверить, кто что видит	Бывшие сотрудники остаются в системах
Резервные копии	Поддержать восстановление	Бэкапы есть, но их не тестируют
Облачные сервисы	Учесть сторонние платформы	Shadow IT не попадает в область

Без списка активов риск-оценка становится абстрактной. Нельзя качественно управлять рисками, если компания не знает, какие данные и системы у нее есть.

Что проверить в рисках до внедрения?

ISO 27001 строится вокруг управления рисками. Поэтому до старта нужно понять, как компания будет выявлять, оценивать, обрабатывать и пересматривать риски информационной безопасности.

Проверьте:

есть ли методика оценки рисков;
кто утверждает критерии риска;
кто владеет каждым риском;
какие угрозы уже известны;
какие уязвимости повторяются;
какие инциденты были раньше;
какие требования есть у клиентов;
какие законы и договоры влияют на безопасность;
какие меры уже внедрены;
какие риски бизнес готов принять;
как документируются решения.

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

Какие роли нужно назначить заранее?

Перед ISO 27001 важно назначить не только «ответственного за сертификат», но и владельцев процессов. Система не заработает, если все решения остаются на одном специалисте по безопасности.

Ключевые роли:

sponsor проекта со стороны руководства;
владелец ISMS;
ответственный за риск-менеджмент;
владельцы активов;
владельцы процессов;
IT-ответственный;
HR-ответственный;
юридический или compliance-ответственный;
ответственный за поставщиков;
внутренний аудитор;
координатор корректирующих действий.

Руководство должно участвовать в решениях о рисках, ресурсах и приоритетах. Если ISO 27001 делегируют только IT-отделу, проект часто превращается в набор технических настроек вместо системы управления.

Какие документы проверить до старта?

Документы не должны существовать отдельно от практики. Перед внедрением важно понять, какие политики уже есть, какие нужно обновить, а какие писать рано, пока не ясны процессы.

Чаще всего проверяют:

политику информационной безопасности;
область действия ISMS;
методику оценки рисков;
реестр рисков;
план обработки рисков;
Statement of Applicability;
реестр активов;
матрицу доступа;
процедуру управления инцидентами;
процедуру управления изменениями;
политику доступа;
политику резервного копирования;
политику поставщиков;
правила удаленной работы;
план внутреннего аудита;
протоколы анализа со стороны руководства.

Statement of Applicability — один из ключевых документов. Он показывает, какие меры из Annex A применяются, почему они выбраны, что исключено и на каком основании.

Что проверить в доступах и учетных записях?

Доступы — один из самых частых источников проблем. Перед ISO 27001 нужно понять, кто имеет доступ к системам, как доступы выдаются, пересматриваются и отзываются.

Проверьте:

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

Если доступы выдаются через сообщения в чате и не фиксируются, это слабое место. Для ISO 27001 важно показать управляемый процесс, а не только наличие паролей.

Что проверить в поставщиках и облачных сервисах?

Поставщики часто оказываются в критичном контуре: хостинг, CRM, бухгалтерия, helpdesk, аналитика, email, платежи, подрядчики разработки, маркетинговые сервисы и облачные платформы. Если они обрабатывают данные или влияют на доступность услуги, их нужно учитывать.

Тип поставщика	Что проверить	Риск
Облачный хостинг	Договор, регион, доступы, резервирование	Потеря доступности или данных
CRM	Права пользователей, экспорт данных, MFA	Утечка клиентской базы
Подрядчик разработки	Доступ к коду и средам	Несанкционированные изменения
Email-сервис	Домены, рассылки, учетные записи	Фишинг и компрометация
Платежный сервис	Договоры, роли, логи	Финансовые и правовые риски
Поддержка клиентов	Доступ к тикетам и персональным данным	Нарушение конфиденциальности

Поставщиков не обязательно исключать. Их нужно оценивать, контролировать и документировать. Особенно если они входят в область ISMS.

Что проверить в инцидентах и резервном копировании?

ISO 27001 требует не только предотвращать проблемы, но и управлять ими. Поэтому до старта стоит проверить, как компания фиксирует инциденты, реагирует на них и восстанавливает работу.

Проверьте:

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

Если бэкапы есть, но их никто не восстанавливал, это не полноценная уверенность. Перед сертификационным проектом полезно провести тест восстановления и зафиксировать результат.

Как понять, готова ли компания к внутреннему аудиту?

Внутренний аудит нужен не в конце «для галочки», а как проверка работы ISMS до внешнего аудита. Он помогает найти несоответствия, пока есть время их исправить.

Компания готова к внутреннему аудиту, если:

область действия утверждена;
ключевые документы актуальны;
риски оценены;
план обработки рисков ведется;
Statement of Applicability подготовлен;
роли назначены;
активы описаны;
доступы управляются;
инциденты фиксируются;
поставщики оценены;
сотрудники прошли базовое обучение;
корректирующие действия отслеживаются.

После внутреннего аудита нужен анализ со стороны руководства. Это не формальная встреча, а управленческий обзор: что работает, где риски, какие ресурсы нужны, какие решения принимает руководство.

Что чаще всего недооценивают перед ISO 27001?

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

Чаще всего забывают:

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

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

Чеклист: что проверить перед стартом ISO 27001

Этот чеклист помогает оценить готовность компании к проекту ISO 27001 до полноценного внедрения. Он помогает увидеть слабые места заранее: область сертификации, активы, риски, роли, документы, доступы, поставщиков, аудит и ресурсы.

Определите цель проекта
Сформулируйте, зачем компании ISO 27001: клиентское требование, тендер, рынок, зрелость безопасности или снижение рисков. Без цели проект легко превращается в формальную подготовку документов.
Уточните область действия
Решите, что именно входит в ISMS: продукт, услуга, офис, команда, инфраструктура, процессы и поставщики. Слишком широкая область усложнит проект, слишком узкая может не решить бизнес-задачу.
Назначьте владельца проекта
Определите ответственного за координацию ISO 27001 и спонсора со стороны руководства. Проекту нужны решения, ресурсы и право вовлекать разные подразделения.
Составьте список активов
Опишите данные, системы, сервисы, устройства, учетные записи, код, документы и облачные платформы. Без активов невозможно качественно оценить риски.
Назначьте владельцев активов
Для каждого важного актива должен быть владелец, который понимает ценность, доступы и риски. IT не должен быть единственным владельцем всех бизнес-данных.
Проверьте управление доступами
Посмотрите, как выдаются, изменяются и отзываются права пользователей. Особое внимание уделите администраторам, общим учетным записям и бывшим сотрудникам.
Проверьте методику рисков
Определите, как компания будет оценивать вероятность, влияние и допустимость риска. Методика должна быть понятной владельцам процессов, а не только специалисту по безопасности.
Подготовьте реестр рисков
Зафиксируйте основные риски по активам, процессам, поставщикам и людям. Для каждого риска нужен владелец, решение и план обработки.
Проверьте документы ISMS
Соберите существующие политики, процедуры, инструкции и журналы. Уберите устаревшие документы и не пишите новые шаблоны без связи с реальной практикой.
Оцените поставщиков
Проверьте облачные сервисы, подрядчиков, хостинг, CRM, платежные и support-системы. Важно понимать, кто имеет доступ к данным и как это контролируется.
Проверьте инциденты и бэкапы
Убедитесь, что инциденты фиксируются, а резервные копии не только создаются, но и тестируются. Восстановление должно быть проверено до внешнего аудита.
Запланируйте внутренний аудит
Не оставляйте внутренний аудит на последнюю неделю. После него должно остаться время на исправление несоответствий и анализ со стороны руководства.
Проверьте бюджет и ресурсы
Учтите не только консультации и аудит, но и исправления, обучение, инструменты, время сотрудников и поддержку системы после сертификации.
Подготовьте руководство
Руководство должно понимать свои решения по рискам, ресурсам и улучшениям. ISO 27001 нельзя полностью делегировать одному IT-специалисту.

Какие ошибки лучше исправить до запуска проекта?

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

Минимальный порядок действий:

Зафиксировать цель сертификации.
Выбрать реалистичную область.
Назначить владельца ISMS.
Собрать реестр активов.
Проверить критичные доступы.
Описать подход к рискам.
Подготовить план внедрения.
Согласовать ресурсы с руководством.

Если эти шаги не выполнены, проект может стартовать красиво, но быстро замедлиться на согласованиях.

FAQ

Что проверить перед ISO 27001 в первую очередь?

Сначала проверьте цель проекта, область действия, поддержку руководства, владельца ISMS, активы, риски, доступы, поставщиков, документы и ресурсы.

Можно ли начать ISO 27001 без реестра активов?

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

Что такое область действия ISO 27001?

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

Кто должен отвечать за ISO 27001?

Нужен владелец ISMS и поддержка руководства. Также нужны владельцы активов, процессов, рисков, доступов, поставщиков и корректирующих действий.

Что такое Statement of Applicability?

Statement of Applicability — документ, который показывает, какие меры контроля применяются, почему они выбраны, что исключено и на каком основании.

Нужно ли проводить внутренний аудит до сертификации?

Да. Внутренний аудит помогает проверить ISMS до внешнего аудита, найти несоответствия и успеть исправить проблемы.

Почему ISO 27001 нельзя делать только силами IT?

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

Сколько времени занимает подготовка к ISO 27001?

Срок зависит от размера компании, области действия, зрелости процессов и готовности документов. Лучше оценивать срок после предварительной проверки готовности.

Глоссарий

ISO 27001 — международный стандарт для системы управления информационной безопасностью.

ISMS — система управления информационной безопасностью, которая описывает, как компания управляет рисками, активами, процессами и улучшениями.

Область действия — границы ISMS: какие продукты, команды, офисы, системы и процессы входят в проект.

Информационный актив — данные, система, сервис, документ, устройство, учетная запись или знание, которое имеет ценность для компании.

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

Владелец риска — человек или роль, которые отвечают за решение по конкретному риску.

Statement of Applicability — документ о применимости мер контроля и обосновании включений или исключений.

Annex A — приложение к ISO 27001 с набором мер контроля информационной безопасности.

Внутренний аудит — проверка ISMS внутри компании до внешнего сертификационного аудита.

Корректирующее действие — действие для устранения причины несоответствия и предотвращения повторения проблемы.

Заключение

Перед ISO 27001 нужно проверить не только документы, но и готовность компании управлять безопасностью: активами, рисками, доступами, поставщиками, инцидентами и решениями руководства. Чем честнее readiness-проверка до старта, тем меньше шансов застрять перед аудитом.

Использованные источники

Официальное описание ISO/IEC 27001 как стандарта для системы управления информационной безопасностью — iso.org/standard/27001

Официальный обзор требований ISO/IEC 27001 к созданию, внедрению, поддержанию и улучшению ISMS — iso.org/obp/ui/en

Обзор Annex A ISO 27001:2022 и 93 мер контроля в четырех категориях — grcsolutions.io/iso-27001-the-14-control-sets-of-annex-a-explained

Разъяснение Statement of Applicability и структуры Annex A ISO 27001:2022 — isms.online/iso-27001/annex-a-2022

Материалы по внутреннему аудиту ISO 27001 и роли проверки ISMS — dataguard.com/iso-27001/audit

Разъяснение требований ISO 27001 по внутреннему аудиту и performance evaluation — isms.online/iso-27001/requirements-2013/9-2-internal-audit-2013

Обзор процесса сертификации ISO 27001, этапов аудита и надзорных проверок — glocertinternational.com/resources/guides/iso-27001-certification-process

Практическое руководство по внутреннему аудиту ISO 27001, management review и follow-up actions — vanta.com/collection/iso-27001/iso-27001-internal-audit

Читать другие статьи из категории: Технологии.