Statement of Applicability (SoA): ключовий документ ISO 27001
Statement of Applicability ISO 27001 — це документ, який перетворює абстрактні вимоги стандарту на чітку відповідь: які саме контролі безпеки ви застосували, чому саме ці, і де це підтверджено документами та доказами. Для бізнесу в Україні SoA часто стає тим самим містком між ризиками, реальними процесами та сертифікаційним аудитом за ISO/IEC 27001:2022.
Що таке SoA ISO 27001 простими словами
SoA ISO 27001 (Statement of Applicability) — це перелік контролів з Annex A ISO 27001, де навпроти кожного контролю вказано:
- застосовується чи ні;
- обґрунтування (чому застосовуєте / чому виключили);
- статус впровадження (впроваджено / частково / в плані);
- посилання на політики, процедури та докази (логи, звіти, налаштування, записи навчань тощо).
Тобто SoA — це паспорт вашої системи захисту, який показує аудитору: ви не просто читали стандарт, а реально керуєте вимогами ISO 27001 до інформаційної безпеки.
Звідки беруться контролі: роль Annex A ISO 27001
Контролі для SoA беруться з Annex A ISO 27001 (у версії 2022 — 93 контролі). Важливий нюанс: SoA — не список галочок, а документ, який має логічно витікати з оцінки ризиків. Якщо контроль позначено “Applicable”, але немає доказів або зв’язку з ризиком — на аудиті це болить.
Як SoA пов’язаний із ризиками та документацією ISO 27001
SoA працює як індекс до всієї вашої системи управління інформаційною безпекою:
- ви оцінюєте ризики (що може піти не так);
- обираєте способи обробки ризиків;
- підбираєте контролі з Annex A;
- фіксуєте це в SoA та підв’язуєте документацію ISO 27001.
Саме тому SoA часто перевіряють одним із перших: він швидко показує зрілість ISMS і те, наскільки керовані у вас рішення з безпеки.
Що обов’язково має містити Statement of Applicability ISO 27001
Перед тим як робити SoA, корисно уявити його як таблицю: один рядок = один контроль Annex A. Нижче — мінімальний набір полів, які роблять документ аудитопридатним.
- Код контролю Annex A (наприклад, A.5.1) і назва
- Застосовність (Applicable / Not applicable)
- Обґрунтування (1–3 речення, без “просто не треба”)
- Статус (Implemented / Partly / Planned)
- Посилання на ризик (Risk Register / Treatment Plan)
- Посилання на документи (політики/процедури/інструкції)
- Докази (логи, звіти, скріни конфігурацій, протоколи навчань)
- Власник контролю (роль) і періодичність перевірки
Після таблиці додайте короткий опис, як ви оновлюєте SoA: наприклад, після змін в інфраструктурі, нових постачальників або інцидентів.
Типові помилки, через які SoA провисає на аудиті
SoA найчастіше псують не складні речі, а дрібні спрощення, які аудитори бачать за кілометр.
- Виключення контролів без нормального пояснення (“не актуально” — не аргумент).
- Немає посилань на докази: контроль ніби є, а підтвердження — “на словах”.
- SoA не стикується з ризиками: ризики одні, контролі — інші.
- Застарілий документ: процеси змінилися, SoA — ні.
- Плутанина між SoA та планом впровадження: SoA фіксує застосовність і стан, а план — кроки проєкту.
Щоб краще зрозуміти логіку етапів сертифікації та підготовки до аудиту, зручно тримати під рукою гайд як отримати сертифікат ISO 27001: покроковий гід.
SoA як інструмент для бізнесу, а не “ще один файл”
Добре зроблений Statement of Applicability ISO 27001 допомагає не тільки пройти аудит, а й говорити з клієнтами та партнерами мовою фактів: що саме у вас захищено і якими контролями. Особливо це цінно для IT та компаній із персональними даними клієнтів, де довіра прямо впливає на продажі.
Якщо вам потрібен супровід у впровадженні та сертифікації, можна відштовхнутися від послуги замовлення сертифікату ISO/IEC 27001 в Україні. А якщо стоїть задача “прокачати команду” перед впровадженням, замовте консультацію в наших менеджерів, щоб швидше вирівняти розуміння стандарту між ІТ, юристами, безпекою та бізнесом.
Команда Систем Менеджмент допомагає оформити SoA так, щоб він був не для галочки, а реально працював у вашій системі управління інформаційною безпекою.
