ISO 27001 без лишнего охвата: как спроектировать СУИБ

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

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

Задайте себе простой вопрос: сертификат должен подтверждать устойчивость всей компании или конкретного направления, которое продаёт, производит либо обслуживает продукт?

Что означает область применения СУИБ

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

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

Хорошая область применения отвечает на пять вопросов:

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

Формулировка «вся информационная деятельность компании» почти всегда слишком расплывчата. Она не помогает понять, что проверять, кто отвечает за результат и какие записи нужно предъявить.

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

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

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

Граница должна быть понятной сотруднику, владельцу процесса и внешнему проверяющему. Если её приходится долго объяснять устно, описание ещё не готово.

Три модели охвата, которые помогают не раздуть СУИБ

Охват по продукту или услуге

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

Охват по подразделению

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

Охват по информационной системе

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

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

Чек-лист перед утверждением области

1. Определите цель проекта и ожидаемый бизнес-результат.
2. Составьте перечень процессов, которые создают этот результат.
3. Нанесите информационные потоки между подразделениями и внешними сторонами.
4. Назначьте владельцев процессов, систем и данных.
5. Проверьте общие сервисы, без которых выбранная область не работает.
6. Отдельно перечислите площадки, удалённые форматы работы и технические зоны.
7. Зафиксируйте исключения и влияние исключённых элементов на охват.
8. Сверьте формулировку с руководством, ИТ, безопасностью, юристами и владельцами процессов.
9. Проверьте, сможете ли вы регулярно поддерживать заявленный охват после завершения проекта.

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

Ошибки, которые увеличивают стоимость проекта

«Включим всё на всякий случай». Такой подход переносит неопределённость в проект. Команда начинает описывать процессы, которые не связаны с заявленной целью, а владельцы тратят время на формальные согласования.

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

Исключение общих сервисов без анализа. Если выбранное направление использует общую учётную запись, сеть, почту или платформу, простая запись «сервис не входит» не объясняет, как управляют связанной зависимостью.

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

Отсутствие владельца границы. Когда никто не отвечает за актуальность области применения, любое изменение структуры или ИТ-ландшафта создаёт спор о том, входит ли новый объект в систему.

Как оформить решение и подготовить расширение

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

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

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

Частые вопросы

Можно ли включить в СУИБ только один отдел?

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

Нужно ли включать всю компанию для подготовки к ISO 27001?

Нет, цель проекта и границы СУИБ можно определить для выбранного направления. Важно ясно показать, что входит в охват, а что остаётся за его пределами.

Можно ли исключить корпоративную почту или общую платформу?

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

Как понять, что область применения получилась слишком широкой?

Проверьте количество процессов, владельцев, площадок и систем. Если команда не может поддерживать их описание и контроль после проекта, охват стоит пересмотреть.

Можно ли расширить СУИБ позже?

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