Statement of Applicability (SoA) — это не табличка для аудитора, а карта ваших решений по защите информации: какие ISO 27001 Controls вы применяете, почему именно их, и как это связано с рисками бизнеса. В Казахстане SoA часто смотрят не только сертификационные аудиторы, но и заказчики в тендерах, партнеры и внутренние службы (ИТ, безопасность, юристы). Поэтому главный принцип простой: SoA должен отражать реальность, а не копировать чужие списки.
Что такое SoA и почему шаблоны вредят
SoA фиксирует:
- выбранные контроли из Annex A;
- обоснование включения/исключения;
- статус внедрения (планируется / внедрено / частично);
- ссылки на политики, процедуры и доказательства.
Когда SoA делают по шаблону, получается красивый документ без связи с реальными рисками. На аудите это видно по типичным признакам: контроль включен, но нет владельца, процедуры и доказательств; или контроль исключен, но риск при этом никак не закрыт.
Как связаны риски, план обработки и Annex A
Правильный выбор контролей начинается не с Annex A, а с оценки рисков и решений по их обработке (Risk Treatment Plan). Логика такая:
- вы определяете активы и сценарии угроз;
- оцениваете риск;
- решаете: снизить / передать / принять / избежать;
- если снижаете — выбираете меры, и часть из них будет из Annex A.
Annex A и Annex B: в чем разница и зачем она в SoA
Фраза “Annex A и Annex B” часто звучит так, будто оба приложения нужно внедрить. На практике:
- Annex A в ISO/IEC 27001 — это перечень контролей (мер), из которых вы выбираете применимые.
- Annex B (в актуальной редакции стандарта) помогает сопоставлять/понимать соответствие структуре и источникам контролей (например, связи с ISO/IEC 27002). Это полезно для навигации, но SoA строится вокруг Annex A, а не вокруг Annex B.
Итог: Annex B — это «подсказка», Annex A — «набор мер», SoA — «ваш выбор и аргументация».
Пошаговый алгоритм выбора контролей Annex A
Ниже — рабочий подход, который выдерживает аудит и здравый смысл. Перед списком зафиксируйте контекст: какие процессы критичны (продажи, сервис, разработка, бухгалтерия), где хранятся данные, какие требования клиентов/законов важны.
- Шаг 1. Привяжите риски к активам и процессам. Не «в целом у нас риск утечки», а «утечка клиентской базы из CRM → финансовый ущерб/репутация/штрафы».
- Шаг 2. Определите цель обработки риска. Например: снизить вероятность, снизить ущерб, повысить обнаружение.
- Шаг 3. Подберите контролы Annex A, которые реально закрывают сценарий. Не больше и не меньше.
- Шаг 4. Проверьте реализуемость. Есть ли бюджет, владелец, сроки, инфраструктура.
- Шаг 5. Заполните SoA: “включен/исключен”, обоснование, статус, доказательства.
- Шаг 6. Пройдитесь «красными флажками» аудитора. Если контроль включен — должны быть артефакты: политика/процедура/логи/записи обучения/результаты тестов.
После списка обязательно сделайте финальную проверку: каждый значимый риск должен иметь понятный мостик к мерам (включая не только Annex A, но и организационные/технические решения).
Частые ошибки, из-за которых SoA сыпется на аудите
SoA обычно падает не из-за формулировок, а из-за несоответствия реальности. Вот типичные промахи:
- “Включили всё” — 90+ контролей отмечены как внедренные, но доказательств нет.
- Нет обоснований исключений. Пишут “не применимо”, не объясняя почему и чем закрыт риск.
- Путают политику и фактическое выполнение. Документ есть, практики нет.
- Не обновляют SoA при изменениях. Новая система/филиал/поставщик — а SoA прежний.
- Контроли висят в воздухе. Нет владельца, метрик, периодичности проверок.
Хорошее правило: если контроль нельзя подтвердить за 5–10 минут на внутренней проверке (показать запись/лог/отчет/скрин/акт), значит в SoA он пока должен быть «в работе», а не «внедрен».
SoA и SOA Сертификация: что реально проверяют
На сертификационном аудите (и особенно на ресертификации) смотрят три вещи:
- Прослеживаемость: риск → решение → контроль → доказательства.
- Актуальность: SoA отражает текущий периметр, ИТ-ландшафт и поставщиков.
- Управляемость: есть ответственные, периодичность, внутренние проверки, корректирующие действия.
Если вы готовитесь к SOA Сертификация, заранее проведите мини-аудит SoA: выберите 10–15 включенных контролей и соберите доказательства в одну папку. Это резко снижает стресс на внешнем аудите.
Мини-шаблон блока SoA, который удобно читать бизнесу
Чтобы SoA был понятен не только аудитору, добавляйте к каждому контролю:
- бизнес-цель (что защищаем);
- рисковый сценарий (от чего защищаем);
- владелец (кто отвечает);
- метрика/проверка (как убеждаемся, что работает).
Так SoA превращается из формальности в управленческий инструмент.
Если хотите, BALTUM BUREAU в Казахстане может помочь собрать SoA под ваш контекст, подобрать ISO 27001 без избыточности и подготовить доказательную базу под аудит.