Заява про застосовність (SoA) ISO 27001 — обґрунтування 93 контролів Додатка А
Розробляємо Заяву про застосовність (Statement of Applicability, SoA) за вимогами ISO/IEC 27001:2022 (пункт 6.1.3). Для кожного з 93 контролів Додатка А — обґрунтована застосовність, посилання на реалізацію, зв'язок з оцінкою ризиків.
Заява про застосовність — найголовніший документ СУІБ після Політики інформаційної безпеки. Аудитор починає Етап 1 сертифікації саме з неї, порівнює її з Планом обробки ризиків, перевіряє на внутрішню логічність. Неякісна SoA — найтиповіша причина суттєвих невідповідностей на сертифікаційному аудиті.
CyberStudy розробляє SoA з 2014 року, у редакції 2022 — від моменту її публікації. За останній рік написано 40+ унікальних Заяв про застосовність для різних галузей: IT та SaaS, фінтех, e-commerce, оператори критичної інфраструктури, телеком.
Навіщо потрібна SoA
Узгодженість з Політикою
Аудитор перевіряє, чи не суперечать зобов’язання Політики ІБ вибору конкретних контролів.
Зв’язок з ризиками
Доводить, що обґрунтування застосовності контролів справді спираються на результати оцінки ризиків.
Реалістичність впровадження
Підтверджує наявність процедур та систем, на які посилається документ як на докази реалізації.
Відсутність «шаблонності»
Показує свідомий вибір набору контролів, унікальний для специфіки та процесів саме вашої компанії.
Структура Додатка А:2022
Нові контролі редакції 2022
11 нових вимог, що з’явилися в стандарті
A.5.7 Threat intelligence
Розвідка загроз — систематичний збір та аналіз інформації про актуальні кіберзагрози.
A.5.23 Безпека у хмарах
Спеціальні вимоги до інформаційної безпеки при використанні хмарних сервісів.
A.8.9-8.12 Data Protection
Управління конфігураціями, видалення інформації, маскування та запобігання витоку (DLP).
A.8.16 & A.8.23 Моніторинг
Моніторинг активності користувачів та веб-фільтрація для захисту від шкідливого контенту.
A.8.28 Secure Coding
Принципи безпечного кодування протягом усього життєвого циклу розробки ПЗ.
Типові помилки в SoA
Формальна застосовність
Коли всі 93 контролі позначені як застосовні без реальних обґрунтувань та доказів.
Слабкі обґрунтування
Формальні фрази типу «не стосується нас» без пояснення конкретних причин виключення.
Розбіжність з ризиками
Коли в SoA контроль виключено, хоча він призначений для обробки ризику в реєстрі.
Неактуальні посилання
Посилання на процедури або системи, які вже не існують або суттєво змінилися.
Стара структура
Використання категорій та 114 контролів старої редакції 2013 року замість нової 2022.
Пишемо SoA тільки після оцінки ризиків. Кожне обґрунтування спирається на конкретну загрозу чи актив.
З’ясовуємо застосовність кожного контролю через спілкування з власниками процесів у вашій компанії.
Проводимо детальний перегляд документа перед передачею аудитору, виправляючи всі критичні невідповідності.
Готові розробити вашу SoA?
Етапи розробки SoA
Уточнюємо наявність оцінки ризиків, сферу СУІБ, мову та терміни. Фіксуємо ціну.
Перевіряємо якість наявної оцінки. Без неї SoA — лише здогадки. За потреби оновлюємо її.
Уточнюємо межі СУІБ: підрозділи, локації, продукти та категорії інформаційних активів.
Розподіл 93 контролів на організаційні, кадрові, фізичні та технологічні для опрацювання.
З’ясовуємо застосовність кожного контролю, шукаємо пов’язані ризики та наявну реалізацію.
Формулюємо обґрунтування для кожного пункту з посиланням на ризики, активи та специфіку.
Вказуємо, як саме реалізовано: посилання на процедуру, технічну систему або документ.
Перевірка документа з керівниками відділів, відповідальних за реалізацію контролів.
Зведення документа, перевірка на несуперечливість та передача на підпис керівництву.