Сертификация по ISO/IEC 27001:2022 не обязательно должна охватывать всю компанию — каждый филиал, отдел и бизнес-процесс. Стандарт позволяет организации определить границы системы менеджмента информационной безопасности с учетом реальных задач бизнеса. И именно от того, насколько грамотно сформирован scope ISO 27001, зависит не только сложность проекта, но и объем аудита, количество вовлеченных сотрудников и в конечном итоге стоимость сертификации ISO 27001.
Ошибка на этом этапе напоминает аренду большого склада для хранения нескольких коробок: формально задача решена, но расходы явно выше необходимых. Поэтому до начала внедрения стоит разобраться, какие процессы действительно должны входить в область действия СУИБ.
Что такое scope ISO 27001
Scope — это границы, в пределах которых действует система менеджмента информационной безопасности, или СУИБ. В документированной области применения компания определяет, какие подразделения, площадки, информационные системы, услуги и процессы охвачены системой.
Например, IT-компания предоставляет клиентам облачный сервис и хочет подтвердить безопасность именно этой услуги. В зависимости от структуры бизнеса в область можно включить подразделения разработки, технической поддержки и эксплуатации инфраструктуры, не распространяя сертификацию автоматически на совершенно не связанные направления.
Однако просто исключить «неудобный» процесс нельзя. ISO/IEC 27001:2022 требует учитывать внутренние и внешние факторы, заинтересованные стороны, а также зависимости между процессами. Если бухгалтерия, дата-центр или подрядчик критически влияют на безопасность сертифицируемой услуги, их роль придется учитывать даже при ограниченном scope.
От чего зависит область сертификации ISO 27001
Правильная область сертификации ISO 27001 начинается не с вопроса «что можно исключить?», а с вопроса «что именно компания хочет подтвердить сертификатом?».
Перед фиксацией границ полезно определить несколько вещей:
- какие продукты или услуги должны быть охвачены сертификатом;
- какие подразделения непосредственно обеспечивают их работу;
- где обрабатывается и хранится критичная информация;
- какие IT-системы, серверы, облачные платформы и рабочие места используются;
- какие офисы, производственные площадки или дата-центры относятся к выбранным процессам;
- какие внешние поставщики и подрядчики имеют доступ к информации или инфраструктуре;
- какие требования клиентов, законодательства и договоров необходимо учитывать.
После такого анализа scope обычно становится значительно понятнее. Компания видит не абстрактную организационную структуру, а цепочку процессов, от которых зависит безопасность конкретной услуги или продукта.
Почему слишком широкий scope увеличивает расходы
Объем сертификационного аудита связан с масштабом и сложностью СУИБ. Чем больше подразделений, процессов, площадок и сотрудников попадает в область, тем больше информации необходимо анализировать аудиторам.
Расширенный scope может означать дополнительные интервью, проверки документов, оценку нескольких площадок и анализ большего числа технических и организационных мер. Кроме того, возрастает внутренняя нагрузка: приходится разрабатывать процедуры и собирать свидетельства выполнения требований сразу для большого количества процессов.
Поэтому подготовка к сертификации ISO 27001 должна начинаться до заказа сертификационного аудита. Сначала целесообразно определить бизнес-цель сертификации, затем провести анализ контекста и только после этого формировать окончательные границы СУИБ.
При этом чрезмерно узкий scope тоже создает риски. Например, область вида «отдел информационной безопасности» часто мало что говорит клиенту, если именно этот отдел не оказывает сертифицируемую услугу. Сертификат должен описывать понятную и логичную часть бизнеса.
Как проверить scope до начала сертификации
Есть простой практический тест. Представьте потенциального клиента, который впервые читает формулировку в сертификате. Должен ли он понять, какая деятельность компании подтверждена сертификацией? Если ответ требует длинного объяснения, формулировку стоит пересмотреть.
Хороший scope обычно содержит три составляющие: деятельность, организационные или физические границы и, при необходимости, связанные продукты или услуги.
Например, вместо общей формулировки «предоставление IT-услуг» полезнее конкретизировать, о каких услугах идет речь и каким подразделением они предоставляются. Это снижает вероятность разногласий на сертификационном аудите и делает сам сертификат более информативным для партнеров.
Особенности для компаний Центральной Азии и Кавказа
Для бизнеса из Казахстана, Узбекистана, Кыргызстана и Грузии вопрос границ СУИБ особенно актуален, если компания работает с зарубежными заказчиками или участвует в международных тендерах. Нередко требование ISO/IEC 27001 относится не ко всему юридическому лицу, а к конкретной услуге, проекту или центру разработки.
Например, внедрение ISO 27001 в Казахстане для IT-компании может быть сфокусировано на разработке и сопровождении SaaS-платформы, если именно это направление должно соответствовать требованиям зарубежных клиентов. Аналогичный подход применим к сервисным компаниям, финтех-проектам, аутсорсинговым центрам и организациям, работающим с конфиденциальными данными.
Специалисты Систем Менеджмент в СНГ рекомендуют рассматривать определение scope как отдельный этап проекта, а не как формальность перед аудитом. Предварительный анализ помогает понять, какие процессы действительно необходимы для достижения целей сертификации, а какие можно обоснованно оставить за ее пределами.
Scope должен работать на бизнес, а не усложнять его
Оптимальная область действия ISO/IEC 27001:2022 — не самая большая и не саая маленькая. Она должна соответствовать бизнес-задачам компании, учитывать реальные информационные риски и быть понятной клиентам и аудиторам.
Если сначала определить цели сертификации, зависимости процессов и границы ответственности, можно заметно сократить лишнюю организационную работу. Такой подход позволяет сделать СУИБ управляемой, а расходы на аудит — прогнозируемыми.
Поэтому еще до разработки политик, процедур и реестров активов стоит уделить время формированию scope. Несколько часов качественного анализа на старте иногда экономят недели работы на последующих этапах сертификационного проекта.

