Statement of Applicability в ISO 27001: что это и зачем нужен SoA

При внедрении ISO/IEC 27001 многие компании быстро сталкиваются с документом, который на практике вызывает больше всего вопросов, — Statement of Applicability (Заявление о применимости), или SoA. Одни воспринимают его как формальную таблицу для аудитора. Другие — как полный перечень всех мер защиты информации. Третьи вообще заполняют SoA по шаблону, не связывая его с оценкой рисков и реальной логикой СУИБ. Между тем именно этот документ часто показывает, насколько система управления информационной безопасностью в компании действительно работает, а не существует только на бумаге.

Если объяснить совсем просто, Statement of Applicability — это документ, в котором организация показывает, какие меры защиты информации для нее действительно необходимы, почему они выбраны, внедрены ли они, и почему часть контролей из Annex A может не применяться. В логике ISO 27001 это один из ключевых мостов между оценкой рисков, выбором контролей и подготовкой к аудиту.

Эта тема особенно важна для компаний, которые проходят внедрение ISO 27001, готовятся к аудиту ISO 27001 или хотят, чтобы система управления информационной безопасностью была понятной не только консультанту и аудитору, но и самому бизнесу. ISO прямо описывает ISO/IEC 27001 как стандарт с требованиями к ISMS, предназначенный для установления, внедрения, поддержания и постоянного улучшения системы, а SoA помогает перевести эту общую логику в практический набор применимых контролей.

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

Проще говоря, SoA отвечает на пять практических вопросов. Какие controls нам нужны? Почему именно они? Взяты ли они из Annex A или из других источников? Реализованы ли они на практике? Почему какие-то controls из Annex A мы не применяем? Именно поэтому SoA важен не как «отчетность ради отчетности», а как рабочий инструмент управления рисками информационной безопасности.

В актуальной логике ISO/IEC 27001:2022 Annex A используется как reference set of controls, то есть как опорный набор для сравнения, а не как автоматический обязательный чек-лист для всех без исключения организаций. Организация сначала определяет необходимые ей controls через риск-ориентированный подход, а затем сравнивает этот набор с Annex A, чтобы убедиться, что ничего важного не упущено.

В зрелой системе управления информационной безопасностью SoA не появляется сам по себе и не должен составляться «с нуля в Excel без контекста». Он возникает после того, как организация определила область применения СУИБ, поняла свой контекст, провела оценку рисков информационной безопасности и выбрала подход к обработке этих рисков.

Логика стандарта здесь проста. Сначала компания определяет риски, связанные с потерей конфиденциальности, целостности и доступности информации. Затем выбирает необходимые меры защиты. После этого сопоставляет их с Annex A и фиксирует результат в Statement of Applicability. Поэтому SoA — это не начальная точка, а итог важной части проектирования СУИБ.

Из этой логики следует важный вывод: хороший SoA нельзя качественно подготовить без нормальной оценки рисков. Если риск-анализ поверхностный, SoA почти всегда превращается либо в механическое копирование Annex A, либо в слабый документ без понятной связи с бизнесом, процессами и реальными сценариями угроз. Это одна из причин, почему аудиторы так внимательно смотрят на него во время сертификационного аудита.

Для бизнеса SoA полезен не только как обязательный элемент для сертификации ISO 27001. Его основная ценность в том, что он делает решения по информационной безопасности прозрачными. Руководство, владельцы процессов, ИТ, ИБ, комплаенс и аудит могут видеть не хаотичный набор мер, а логику: какие controls действительно нужны компании и по какой причине.

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

На практике SoA также удобен как точка синхронизации между документами и реальной операционной средой. Через него можно связать политику информационной безопасности, управление доступом, работу с поставщиками, инциденты, резервное копирование, облачные сервисы, удаленный доступ, кадровые процессы и другие элементы СУИБ. Чем лучше SoA отражает эту картину, тем выше зрелость подхода. Это уже вывод из требований и официальных пояснений ISO/IEC 27001, а не отдельное прямое требование стандарта.

Одна из самых частых ошибок — считать, что SoA это просто таблица соответствия Annex A. Официальные разъяснения по ISO/IEC 27001 прямо подчеркивают, что SoA не сводится к конформанс-таблице, описывающей, как организация выполняет controls из Annex A. Он должен отражать именно необходимые controls организации, их обоснование, статус внедрения и причины исключений.

SoA также не является полным перечнем всех документов СУИБ, не заменяет risk register, не заменяет risk treatment plan и не доказывает сам по себе, что control реально работает. Это важный, но не самодостаточный документ. Если в SoA написано, что контроль внедрен, а на практике процесс не работает, аудит быстро выявит этот разрыв. Это уже практический вывод из того, как SoA используется в аудите.

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

В рабочем и зрелом виде Statement of Applicability обычно содержит несколько базовых элементов:

Стандартная и удобная форма SoA на практике часто выглядит как таблица. В ней могут быть колонки: код и название control, источник control, статус внедрения, justification, ссылка на процедуру или владельца, комментарий по применимости. Но сама структура не обязана полностью повторять структуру Annex A. Официальные пояснения как раз поднимают вопрос, должен ли SoA копировать Annex A, и логика ответа — нет, не обязан, если документ выполняет свою функцию корректно.

Связь между SoA и приложением A ISO 27001 часто понимают неправильно. Annex A — это не полный и не автоматически обязательный для всех список controls, а нормативное приложение, которое используется в контексте выбора controls и проверки того, что в ходе risk treatment ничего важного не забыто. Его назначение — быть ориентиром и reference set для сравнения.

Это значит, что наличие control в Annex A само по себе еще не делает его обязательным именно для вашей компании. Если related risk отсутствует, если риск приемлем в существующем контексте или если control заменен другим, организация может обосновать исключение. Но это обоснование должно быть осмысленным и связано с контекстом, рисками и интересами заинтересованных сторон, а не с формулой «нам это неудобно».

Одновременно важно помнить обратную сторону: не все необходимые controls обязаны быть только из Annex A. Официальные разъяснения по ISO/IEC 27001 прямо указывают, что организация может использовать дополнительные источники controls и разрабатывать собственные controls, если этого требуют ее риски, отрасль, клиенты, регуляторы или архитектура процессов. В примерах таких источников упоминаются и другие стандарты, и отраслевые фреймворки.

Это особенно важно для компаний, работающих в облаке, в fintech, в критической инфраструктуре, в сфере персональных данных или по требованиям крупных корпоративных заказчиков. В таких случаях организации часто используют controls не только из Annex A, но и из отраслевых или регуляторных источников, а также собственные custom controls. Это допустимо и соответствует риск-ориентированной логике ISO 27001.

Например, если компания оказывает облачные услуги, ей может быть недостаточно только базового сопоставления с Annex A. Если она работает с карточными данными, требования к controls могут расширяться за счет отраслевых обязательств. Если у нее сложная DevSecOps-среда, могут появляться дополнительные внутренние controls по пайплайнам, секретам, контейнерам или разделению сред. В зрелом SoA такие controls не прячут «за скобки», а явно отражают и обосновывают. Это практический вывод из официального принципа, что Annex A не является исчерпывающим набором.

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

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

Самая частая ошибка — копирование всех controls из Annex A без реального обоснования. Такой SoA выглядит «полным», но на деле скрывает слабую оценку рисков и незрелый подход к СУИБ. Аудитор почти всегда видит это по формальным justification, одинаковым статусам и отсутствию связи с процессами компании.

Вторая ошибка — обратная: исключать controls слишком смело и слишком кратко. Формулировки вроде «не применимо», «не используется», «неактуально» без объяснения редко выглядят убедительно. Исключение должно быть связано с отсутствием соответствующего риска, приемлемостью риска или заменой другим control.

Третья ошибка — не включать в SoA controls, которые выполняются внешними поставщиками. Если нужная мера реализуется внешней организацией, это не снимает ее из логики СУИБ. В официальных разъяснениях прямо указано, что даже при сильной зависимости от externally provided services такой control должен быть отражен в SoA, если он необходим для управления риском.

Во время аудита ISO 27001 SoA часто становится одним из самых удобных документов для проверки зрелости СУИБ. Через него аудитор понимает, как организация мыслит: формально или по существу. Если SoA связан с рисками, владельцами процессов, реальными controls и документированной информацией, это обычно признак рабочей системы.

Аудитор обычно смотрит на несколько вещей: есть ли связь между рисками и выбранными controls, понятны ли причины исключения controls из Annex A, не забыты ли важные меры защиты, соответствует ли статус controls фактической практике, и не выглядит ли SoA как шаблон без связи с контекстом организации. Кроме того, для сертификационной деятельности версия SoA должна быть идентифицирована в сертификационных документах.

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

При этом компания может не включать некоторые controls из Annex A в прямом виде, если они не связаны с ее контекстом или если риск закрывается иным способом. Но в SoA она должна объяснить почему. Если, например, часть инфраструктурных controls выполняет облачный провайдер, это не означает, что их можно просто удалить из картины. Их нужно отразить как необходимые controls, реализуемые через внешнего поставщика и договорные механизмы контроля.

Statement of Applicability в ISO 27001 — это не приложение «для галочки» и не технический список из Annex A. Это один из ключевых документов, через который компания показывает зрелость своей СУИБ, логику выбора мер защиты информации и связь между рисками, controls и реальной практикой.

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

Если сформулировать совсем просто, SoA — это карта применимости controls в вашей системе управления информационной безопасностью. И чем лучше она связана с реальными рисками, процессами и ответственностью, тем сильнее вся система. Это вывод, который напрямую следует из официальной логики ISO/IEC 27001:2022, Annex A и разъяснений по SoA.

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

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

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