Когда область действия определена, а ответственный за СУИБ назначен, можно оценивать риски ИБ. Требования к оценке описаны в разделе 6.1 основной части стандарта.

Тимофей Крылов

Консультант отдела методологии и практик управления кибербезопасностью Infosecurity

Содержание

Шаг 3. Провести анализ и оценку рисков ИБ.
Шаг 4. Разработать документацию по ИБ.
Шаг 5. Внедрить контроли (меры защиты) и обучить персонал.
Читайте также

О чем этот гайд. Внедрение сертификата ISO/IEC 27001 – тема обширная и непростая. До сертификационного аудита нужно пройти восемь шагов, и каждый требует отдельного разбора. Материала получилось много, поэтому мы разделили гайд на три части:Часть 1. Основы стандарта, область действия и роли (шаги 1–2)Часть 2. Оценка рисков, документация и внедрение контролей (шаги 3–5) – вы читаете эту частьЧасть 3. Оценка эффективности, аудиты и сертификация (шаги 6–8)Нумерация шагов сквозная: эта часть начинается с шага 3. Если вы еще не читали предыдущие части, лучше начать с них.

Шаг 3. Провести анализ и оценку рисков ИБ.

Стандарт основан на риск-ориентированном подходе. Оценка рисков ИБ – центральный элемент всей СУИБ: именно она определяет, какие контроли Приложения А применимы, а значит, как будут защищены информационные и другие активы организации.

Прежде чем оценивать риски ИБ, определите методологию управления рисками. Стандарт не навязывает конкретную методологию. Важно, чтобы она была задокументирована, последовательно применялась и давала воспроизводимые результаты. Оценка может быть количественной или качественной – выберите подход, который соответствует зрелости вашей организации.

В разделе 6 стандарт ссылается на документ по управлению рисками ISO/IEC 27005. Он описывает риск-менеджмент как непрерывный процесс и делает упор на вовлечение владельцев рисков и других заинтересованных сторон на всех этапах, а не только при утверждении итогов.

Стандарт требует оформить методику управления рисками ИБ как документированную информацию. Распространенная ошибка – начинать оценку, пока не утверждены четкие критерии управления рисками.

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

На этом шаге нужно собрать много информации. Первичную инвентаризацию обычно проводят при определении области действия (шаг 1 – см. часть 1 гайда), а сейчас дополните данные о вторичных активах (оборудовании, программном обеспечении, базах данных и хранилищах информации), критически важных для организации. Так вы лучше поймете, где сосредоточены риски.

Например, используются ли локальные учетные записи в информационных системах и как они управляются? Разработаны ли планы аварийного восстановления (DRP) на случай недоступности системы? Как часто снимаются резервные копии и какая у системы парольная политика?

Дополнительный источник сведений – произошедшие инциденты и события ИБ. Проанализируйте прошлые инциденты и отчеты о нарушениях (например, об утечках данных, заражении вредоносным ПО или несанкционированном доступе). Изучите журналы службы поддержки, чтобы найти повторяющиеся технические проблемы – они могут указывать на слабые места.

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

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

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

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

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

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

После оценки для каждого риска выше уровня принятия нужно определить способ обработки. Результат оформляется как план обработки рисков – документ с конкретными мерами, ответственными и сроками. Параллельно разрабатывается Заявление о применимости механизмов контролей (SoA): по каждому из 93 контролей Приложения А фиксируется, применяется ли он и почему.

Риски ИБ обрабатывают одним из четырех способов:

снижение риска – самый распространенный способ: внедрить новые меры или повысить эффективность существующих.

Например, в компании высокий риск фишинговой атаки. Чтобы снизить ее вероятность и последствия, можно применить следующие контроли Приложения А:А.6.3. Осведомленность, образование и подготовка в сфере информационной безопасности. Внедрите эффективную программу обучения по ИБ, чтобы сотрудники умели распознавать фишинговые письма, соблюдали правила работы с электронной почтой и знали, как действовать при получении подозрительного письма. Этот контроль снизит вероятность успешной атаки.А.8.5 Безопасная аутентификация. Внедрите двухфакторную аутентификацию для доступа ко всем критически важным системам и конфиденциальным данным. Этот контроль снизит последствия атаки: даже при компрометации пароля злоумышленнику понадобится второй фактор.

Подбирая меры по снижению риска, проверьте применимость всех контролей Приложения А. Меры обработки рисков фиксируются в заявлении о применимости.

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

Все риски выше уровня принятия (определенного по методологии) не могут быть приняты и должны быть снижены.

Заявление о применимости – карта всей СУИБ для аудитора. В нем закреплено, какие контроли Приложения А применимы к вашей организации, а какие нет. Цель документа – обосновать включение или исключение каждой меры и показать, что выбранные меры соответствуют выявленным рискам, законодательным требованиям и бизнес-целям.

Стандарт ориентирован на риски и адаптируется к условиям организации: ее бизнес-требованиям, операционной среде и профилю рисков. Поэтому не все контроли Приложения А будут для вас актуальны, и нужно определить, какие из них внедрять.

Приложение А (Annex A) применяется избирательно на основании как минимум следующих данных:

Результаты оценки и план обработки рисков – какие меры нужны, чтобы снизить конкретные риски ИБ
Требования заинтересованных сторон – клиентов, регуляторов, партнеров, акционеров, которые могут требовать или рекомендовать определенные контроли ИБ (например, клиент требует применения шифрования при хранении данных)
Требования законодательства и других нормативных актов – законодательные, отраслевые, лицензионные требования, которые требуют применять контроли ИБ
Цели ИБ и стратегия компании – иногда контроль внедряют, потому что он поддерживает более широкую цель организации в области ИБ

Заявление о применимости оформляется по такой форме:

Пункт стандарта	Формулировка	Требование	Применимость	Обоснование	Используемые средства и мероприятия

Неприменимость контроля тоже нужно обосновать документально: возможно, он не относится к деятельности вашей организации или к ее среде рисков. Какой бы ни была причина, обязательно укажите в SoA контроли, которые вы исключаете из СУИБ. Например, если в область сертификации не входят процессы разработки ПО, эти контроли можно исключить.

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

Оценка рисков ИБ – не разовое мероприятие, а постоянный процесс. Стандарт требует проводить ее через запланированные интервалы (раз в год) и при существенных изменениях: контекста компании, появлении новых угроз, внедрении новой информационной системы.

Еще один важный шаг – разработка целей ИБ. Они должны быть согласованы со стратегическими целями политики информационной безопасности и учитывать результаты оценки рисков.

Цели ИБ должны быть достижимыми, измеримыми и оформленными как документированная информация.

Шаг 4. Разработать документацию по ИБ.

Обязательный шаг внедрения – разработка документации по ИБ, которая регламентирует требования к защите информации. Комплект документов – основа работы СУИБ.

Документы должны обеспечивать информационную безопасность и при этом учитывать потребности повседневной работы. Чрезмерно жесткие политики мешают продуктивности и вызывают сопротивление работников основных бизнес-подразделений.

Стандарт закрепляет следующие обязательные документы (в скобках – разделы основной части):

Документ, определяющий область действия (разделы 4.1 и 4.2);
Политика информационной безопасности (раздел 5.2);
Методика управления рисками ИБ (раздел 6.1);
Порядок управления документацией по ИБ (раздел 7.5);
Методика проведения оценки эффективности (раздел 9.1);
Порядок проведения внутренних аудитов (раздел 9.2).

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

Чтобы СУИБ соответствовала компании, документация должна развиваться: меняться вместе с целями компании и требованиями заинтересованных сторон.

Для требований Приложения А стандарт ISO/IEC 27001 не дает четкого перечня документов, но он есть в ISO/IEC 27002. Это документация по следующим процессам:

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

Затем определите, какие документы по ИБ нужны каждой категории работников. Например, работникам, не участвующим в разработке ПО, нет необходимости соблюдать требования по безопасной разработке.Важно: Вся документация должна быть утверждена в соответствии с принятой в компании практикой. Работников нужно ознакомить с применимыми к ним документами по ИБ под подпись и сохранить факт ознакомления как документальное свидетельство.

Распространенная ошибка – сделать документацию «для галочки»: скопировать шаблон из интернета, не адаптировав под реальные процессы компании. Аудитор быстро увидит, что реальные процессы не соответствуют документации.

Кроме того, согласно разделу 7.5 основной части нужно купить официальную версию стандарта: это документ внешнего происхождения, на который распространяется авторское право. Ее отсутствие – несоответствие. Учтите, что у ISO/IEC 27001 нет официального перевода на русский язык.

Шаг 5. Внедрить контроли (меры защиты) и обучить персонал.

Следующий шаг – внедрить применимые контроли Приложения А и привести процессы компании в соответствие с разработанной документацией. Это самый ресурсоемкий этап внедрения стандарта.

Это могут быть, например, такие активности:

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

Руководство должно выделить достаточно ресурсов, чтобы встроить СУИБ в процессы компании. Например, по требованиям Приложения А новые поставщики должны проходить оценку рисков ИБ и до начала работы подписывать договор или дополнительное соглашение с требованиями по ИБ. Нередко процесс формально описан, но на практике отдел ИБ в управление поставщиками не привлекается (если это выявят на сертификационном аудите, вы получите несоответствие).

На этом этапе важно фиксировать документальные свидетельства того, что процессы работают в соответствии с документацией по ИБ. Мало внедрить контроль – нужно показать аудитору, что он работает: логи, скриншоты настроек, журналы обучения, подписанные документы. Контроль, который «вроде бы есть», но не подтвержден свидетельствами, с точки зрения аудита равносилен отсутствующему.

Компания должна внедрить все контроли Приложения А, которые определила как применимые в заявлении о применимости.

Рекомендации по применению контролей Приложения А даны в стандарте ISO/IEC 27002. Он детально описывает, как реализовать каждый из 93 контролей и какие практические шаги стоит рассмотреть при внедрении.

Стандарт требует регулярно обучать персонал основам ИБ. Требования к осведомленности работников изложены в разделе 7.3 основной части. Обучать можно любым удобным способом: внедрить специальную систему обучения, рассылать материалы, провести вебинар. Главное – сохранять материалы обучения как документальное свидетельство.

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

Кроме того, оценивайте эффективность обучения, как минимум по двум метрикам:

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

Эти метрики можно оценивать отдельно или в составе общей оценки эффективности процессов ИБ.

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

Обучение по основам ИБ нужно проводить регулярно (не реже одного раза в год). Хорошая практика – дополнительные обучающие мероприятия, например регулярные рассылки о новых угрозах ИБ.

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

Продолжение читайте здесь: Часть 3. Оценка эффективности, аудиты и сертификация (шаги 6–8). В следующей части разберем оценку эффективности, внутренние аудиты, отчет руководству и прохождение сертификационного аудита.

Остались вопросы?

Оставьте свои контактные данные, чтобы мы могли связаться с вами для дальнейших шагов.

КИИ

Информационная безопасность в финансовом секторе: новый подход к оценке и защите

Постановление № 92 от 06.02.2026: новые правила категорирования КИИ в банках, ежегодная отчётность, штрафы по ст. 13.12.2 КоАП и что делать банкам.

06.11.2026

Читать

Законодательство

Cookie и персональные данные: что нужно учитывать владельцам сайтов

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

07.11.2026

Читать

Ai / Безопасность ИИ

Этапы подготовки к сертификации ISO/IEC 42001

Что такое ISO/IEC 42001 и как подготовиться к сертификации: структура стандарта, 5 этапов от обследования до аудита, цикл PDCA.

10.11.2026

Читать

Сертификация ISO

10 шагов по внедрению ISO/IEC 27001

Пошаговый план внедрения ISO/IEC 27001 в 10 шагов: от области применения СУИБ до внутреннего аудита. Типовой срок подготовки — 5–12 месяцев.

05.11.2026

Читать

Другие статьи

Все статьи

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

Оставайтесь на шаг впереди

Дайджесты

Акции

Чек-листы

Памятки

Новые услуги

Ультимативный гайд по внедрению стандарта ISO/IEC 27001. Часть 2: оценка рисков, документация и внедрение контролей

Содержание

Шаг 3. Провести анализ и оценку рисков ИБ.

Шаг 4. Разработать документацию по ИБ.

Шаг 5. Внедрить контроли (меры защиты) и обучить персонал.

Читайте также:

Остались вопросы?

Информационная безопасность в финансовом секторе: новый подход к оценке и защите

Cookie и персональные данные: что нужно учитывать владельцам сайтов

Этапы подготовки к сертификации ISO/IEC 42001

10 шагов по внедрению ISO/IEC 27001

Другие статьи

feeds:title