Цели информационной безопасности по ISO 27001: как устанавливать и оценивать

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

Для ISO/IEC 27001 это важная часть логики системы менеджмента. Сам стандарт рассматривает СУИБ как инструмент управления рисками, устойчивости и операционной результативности, а не как набор ИТ-мер или документов “для проверки”. статья будет полезна компаниям, которые внедряют ISO 27001, пересматривают свои цели в области информационной безопасности, готовятся к внутреннему аудиту или хотят сделать СУИБ полезной для бизнеса, а не только формально соответствующей требованиям.

Что это такое простыми словами

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

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

В логике ISO/IEC 27001:2022 цели должны поддерживать политику информационной безопасности, быть развернуты в relevant parts of the organization и иметь планы достижения. В версии 2022 отдельно усилено требование именно к мониторингу целей, что связывает их с последующим анализом результативности СУИБ. Зачем компании нужны цели в области информационной безопасности

Хорошие цели помогают компании не распыляться на абстрактное “усиление защиты”, а управлять конкретными рисками и процессами.

Бизнесу они нужны как минимум по пяти причинам.

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

Во-вторых, цели делают СУИБ измеримой. Без них система быстро превращается в набор политик, процедур и записей, по которым трудно понять, работает ли она реально.

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

В-четвертых, цели создают основу для мониторинга и анализа. Комитет SC 27 прямо поясняет, что в редакции 2022 требуется мониторить именно выполнение целей, а это дает прямую связку между целями и последующей оценкой результативности. ятых, цели полезны на аудите ISO 27001. По ним видно, является ли СУИБ живой системой менеджмента или просто набором шаблонов.

Как цели связаны с ISO/IEC 27001, политикой и оценкой рисков

Цели не должны появляться “сами по себе”. Зрелый подход строится сверху вниз.

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

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

Это важно и по другой причине: ISO/IEC 27001 использует риск-ориентированный подход, а Annex A нужен не как универсальный чек-лист, а как средство сравнить выбранные компанией меры с базовым набором контролей и не упустить необходимое. То же касается и целей: они должны вытекать из реальных рисков, а не из желания красиво заполнить план. Какими должны быть хорошие цели

Плохая цель звучит так: “повысить уровень информационной безопасности компании”.

Хорошая цель звучит так: “до конца года добиться, чтобы 100% критичных учетных записей проходили квартальный пересмотр владельцами систем” или “снизить средний срок закрытия критичных инцидентов до 24 часов”.

На практике удобно использовать логику SMART. Стандарт не требует именно эту методику по названию, но ее удобно применять, потому что она помогает превратить общие намерения в управляемые цели.

Хорошая цель обычно обладает такими признаками:

Specific — понятна и не допускает двойного толкования;
Measurable — ее можно оценить по метрике, признаку выполнения или качественному критерию;
Achievable — она реалистична для текущей зрелости компании;
Relevant — связана с рисками, политикой и задачами бизнеса;
Time-bound — имеет срок или период оценки.

Здесь есть важный нюанс. В пояснениях SC 27 отмечается, что цели должны быть измеримыми, если это практически возможно, но измеримость не сводится только к цифрам. Иногда допустим и качественный результат — например, “да/нет”, если он подтверждается объективными доказательствами. Кто участвует в установлении целей

Незрелый подход — когда цели по ИБ формулирует только один специалист по безопасности и потом рассылает их остальным.

Зрелый подход — когда в этой работе участвуют руководство, владелец СУИБ, ИТ, ИБ, владельцы процессов, HR, закупки, юридическая функция и другие подразделения, если они реально влияют на риски или исполнение мер.

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

Как формулировать цели правильно

Рабочая последовательность обычно выглядит так:

Посмотреть на политику информационной безопасности и ключевые риски.
Выделить 3–7 приоритетных направлений, а не двадцать формальных целей сразу.
Для каждой цели определить показатель, срок, ответственного и способ контроля.
Зафиксировать, какие действия нужны для достижения результата.
Согласовать цели с владельцами процессов, а не просто “спустить” их вниз.

Удобная практическая формула такая:

Цель = ожидаемый результат + показатель + срок + ответственный + способ оценки.

Например:

сократить долю просроченных пересмотров доступа к критичным системам до 5% к 31 декабря;
обеспечить прохождение вводного ИБ-обучения 100% новых сотрудников в течение 10 рабочих дней;
снизить число повторяющихся инцидентов одного типа на 30% за полугодие.

Какие показатели можно использовать

Для оценки целей подходят не только “большие” KPI. В СУИБ часто полезнее простые и понятные метрики:

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

Главное — не собирать метрики ради красивого дашборда. Они должны помогать принимать решения.

Как оценивать результативность целей

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

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

То же самое с управлением инцидентами информационной безопасности. Если команда “закрывает тикеты”, это не значит, что цель достигнута. Нужно смотреть, улучшается ли время реакции, снижается ли ущерб, устраняются ли корневые причины.

Именно поэтому аудиторы смотрят не только на наличие целей, но и на то, как компания мониторит их выполнение, анализирует отклонения и использует результаты для улучшения СУИБ. Что делать, если цель не достигнута

Не достигнутая цель — это не всегда провал. Иногда это самый полезный сигнал в системе.

Важно разобраться:

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

После этого цель можно скорректировать, разбить на этапы, изменить метрику или пересмотреть сам подход. Хуже всего делать вид, что цель достигнута “формально”.

Типовые ошибки и слабые места

На практике компании чаще всего ошибаются так:

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

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

Что проверяют на аудите

На аудите ISO 27001 обычно смотрят не на красоту формулировок, а на логику.

Аудитор хочет понять:

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

Если цели живут только в таблице “для аудита”, это быстро становится заметно.

Итоги

Цели информационной безопасности по ISO 27001 — это не декоративный раздел СУИБ и не формальная обязанность перед сертификацией ISO 27001. Это инструмент, который делает систему управления информационной безопасностью измеримой, управляемой и полезной для бизнеса.

Хорошая цель связана с политикой, рисками и реальными процессами компании. Она понятна, реалистична, отслеживается во времени и помогает принимать решения. А лучший практический способ формулировать такие цели — брать требования ISO/IEC 27001:2022 и переводить их в ясные SMART-ориентированные результаты, за которыми можно наблюдать и которые можно честно оценить.

Полезные сервисы и ресурсы по сертификации ISO

Планируете пройти сертификацию по ГОСТ Р ИСО/МЭК 27001 или другим стандартам? Отправьте одну заявку и получите до 5 коммерческих предложений за 1 раз только от аккредитованных ФСА органов по сертификации.

📢 Подписывайтесь на наш Telegram-канал с новостями и статьями по ISO;
💬 Присоединяйтесь к чату специалистов по системам менеджмента;
💰 Рассчитайте примерную стоимость сертификации в нашем онлайн-калькуляторе;
🗺️ Найдите орган по сертификации в нашем реестре — по стандарту или прямо на карте.