Как выбрать область применения СУИБ по ISO 27001 без лишнего проекта

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

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

Что именно входит в область СУИБ

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

Граница должна отвечать на несколько практических вопросов:

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

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

Как выбрать границы: практический алгоритм

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

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

Как не раздуть проект

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

Используйте несколько ограничителей:

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

Что проверить до утверждения области

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

Используйте чек-лист:

• Результат. Понятно, какой сервис или процесс покрывает СУИБ.
• Ответственность. Назначены владельцы включённых процессов и активов.
• Зависимости. Учтены общие системы, поставщики и внешние услуги.
• Границы. Понятно, какие подразделения, площадки и ресурсы включены.
• Интерфейсы. Описана передача данных и взаимодействие с исключённой частью бизнеса.
• Риски. Область позволяет оценивать значимые риски, а не только формировать список документов.
• Коммуникация. Формулировка понятна руководству, сотрудникам и внешним участникам.
• Изменения. Определено, кто и когда пересматривает границы при запуске новых сервисов или перестройке процессов.

Типичные ошибки при выборе области

«Вся компания» без расшифровки. Такая формулировка выглядит масштабно, но не объясняет, какие процессы и активы реально управляются.

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

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

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

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

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

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

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

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

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

Хорошая область применения не минимальна и не максимальна. Она достаточна для управления рисками конкретной деятельности, понятна участникам и может поддерживаться в рабочем состоянии.

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

Можно ли начать с одного подразделения?

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

Нужно ли включать всю ИТ-инфраструктуру?

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

Как поступить с внешним поставщиком?

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

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

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

Что важнее при выборе области: требования заказчика или внутренняя структура?

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