Що таке Заява про застосовність (SoA)?

Огляд

Заява про застосовність (SoA) — це обов'язковий документ ISO 27001, який містить перелік усіх 93 контрольних заходів Додатка A та пояснює, чи включено кожен захід до вашої СУІБ або виключено. Для включених заходів описується, як вони реалізовані. Для виключених — надається обґрунтування виключення.

Що це означає на практиці

SoA — це ваш план вибору контрольних заходів, який пов'язує результати оцінки ризиків зі специфічними заходами безпеки, які ви вирішили впровадити. Аудитори використовують його як дорожню карту для перевірки того, що ваша СУІБ належним чином враховує виявлені ризики.

Чому SoA важлива для ISO 27001

Обов'язкова вимога

Пункт 6.1.3(d) ISO 27001 прямо вимагає ведення "Заяви про застосовність, що містить необхідні контрольні заходи та обґрунтування їх включення та виключення". Ви не зможете отримати сертифікацію без повної та точної SoA.

Демонстрація підходу, заснованого на ризиках

SoA доводить, що ви не випадково впроваджуєте контрольні заходи або сліпо застосовуєте шаблони. Вона показує, як кожне рішення щодо контролю пов'язане з вашою оцінкою ризиків.

Дорожня карта для аудиту

Аудитори використовують вашу SoA для планування того, що вони перевірятимуть під час сертифікаційних аудитів. Для включених контрольних заходів потрібні докази їх впровадження та ефективності. Виключення повинні бути обґрунтовані на основі оцінки ризиків або бізнес-контексту.

Управління змінами

У міру зміни ризиків ваша SoA повинна оновлюватися, щоб відображати нові вимоги до контрольних заходів або дозволяти видалення раніше виключених заходів, якщо ризики зменшуються.

Що повинна містити SoA

Повний перелік контрольних заходів

Усі 93 контрольні заходи Додатка A з ISO 27001:2022 повинні бути наведені у вашій SoA, організовані за темами:

• Організаційні заходи: A.5.1 до A.5.37 (37 заходів)
• Заходи щодо персоналу: A.6.1 до A.6.8 (8 заходів)
• Фізичні заходи: A.7.1 до A.7.14 (14 заходів)
• Технологічні заходи: A.8.1 до A.8.34 (34 заходи)

Статус включення/виключення

Для кожного контрольного заходу чітко зазначте, чи включено його до вашої СУІБ, чи виключено. Уникайте неоднозначних статусів, таких як "частково застосовний" — заходи або включені, або виключені.

Опис реалізації (для включених заходів)

Коротко опишіть, як ви реалізуєте кожен включений контрольний захід. Включіть:

• Конкретні політики, процедури або технології, що використовуються
• Хто відповідає за контрольний захід
• Де можна знайти докази реалізації
• Як контрольний захід усуває виявлені ризики

Обґрунтування виключення (для виключених заходів)

Поясніть, чому виключені контрольні заходи не є частиною вашої СУІБ. Допустимі обґрунтування:

• На основі ризиків: "У нашій оцінці немає ризиків, які потребують цього контрольного заходу"
• На основі контексту: "Не застосовно — ми працюємо лише в хмарі без фізичної інфраструктури"
• Юридичні/регуляторні: "Заборонено законами про резидентність даних у нашій юрисдикції"

Структура та формат SoA

Табличний формат (найпоширеніший)

Таблиця з колонками для:

• Номер контрольного заходу (наприклад, A.5.1)
• Назва контрольного заходу (наприклад, "Політики інформаційної безпеки")
• Статус (Включено / Виключено)
• Опис реалізації або обґрунтування виключення
• Посилання на ризик (зв'язок з реєстром ризиків)
• Місце розташування доказів (необов'язково, але корисно)

Описовий формат

Деякі організації віддають перевагу описовому документу, який описує реалізацію контрольних заходів, згрупованих за темами. Менш поширений, але прийнятний варіант, якщо чітко розглянуто всі 93 заходи.

Формат на основі інструментів

Платформи GRC та інструменти СУІБ часто автоматично генерують SoA на основі вибору контрольних заходів та зв'язку з оцінками ризиків. Проте вони все одно потребують ручної перевірки на точність.

Створення вашої SoA

Крок 1: Завершіть оцінку ризиків

Ваша SoA є прямим результатом оцінки ризиків. Визначте всі ризики, що потребують обробки, перш ніж вирішувати, які контрольні заходи впроваджувати.

Крок 2: Зіставте контрольні заходи з ризиками

Для кожного ризику, що потребує обробки, визначте, які контрольні заходи Додатка A зменшать його до прийнятного рівня. Один ризик може потребувати кількох заходів; один захід може усувати кілька ризиків.

Крок 3: Визначте включення/виключення

Контрольні заходи, що усувають виявлені ризики, включаються. Заходи, що не усувають жодного з ваших ризиків, можуть бути виключені (з обґрунтуванням).

Крок 4: Опишіть реалізацію

Для включених контрольних заходів задокументуйте, як ви їх реалізуєте. Будьте достатньо конкретними, щоб аудитори зрозуміли ваш підхід, не дублюючи повні процедури.

Крок 5: Обґрунтуйте виключення

Для виключених контрольних заходів поясніть, чому, спираючись на вашу оцінку ризиків або організаційний контекст. По можливості посилайтеся на конкретні висновки з вашого реєстру ризиків.

Крок 6: Перегляд та затвердження

Керівництво повинно офіційно переглянути та затвердити SoA, визнавши рішення щодо вибору контрольних заходів та будь-які залишкові ризики.

Поширені помилки в SoA

Виключення занадто багатьох контрольних заходів

Організації іноді виключають контрольні заходи, щоб зменшити зусилля з впровадження. Аудитори ретельно перевіряють виключення — якщо ваша оцінка ризиків ґрунтовна, більшість заходів повинні бути включені.

Узагальнені описи реалізації

Копіювання описів контрольних заходів з ISO 27002 без опису вашої фактичної реалізації. Аудиторам потрібно зрозуміти, що робите ви, а не що говорить стандарт.

Відсутність зв'язку з ризиками

Не вдається пов'язати контрольні заходи з конкретними ризиками у вашій оцінці ризиків. Це порушує простежуваність і свідчить про довільний вибір заходів.

Неповне охоплення

Забування розглянути всі 93 контрольні заходи. Навіть якщо захід очевидно не застосовний, він повинен бути зазначений у SoA з обґрунтуванням виключення.

Відсутність циклу перегляду

Створення SoA один раз під час початкового впровадження та ніколи не оновлення її, незважаючи на організаційні зміни або нові ризики.

SoA та інші документи ISO 27001

SoA vs. План обробки ризиків

План обробки ризиків деталізує, як ви будете впроваджувати вибрані контрольні заходи (терміни, відповідальні особи, ресурси). SoA заявляє, які заходи впроваджено та чому. Ці два документи доповнюють один одного.

SoA vs. Докази контрольних заходів

SoA описує, які контрольні заходи ви впроваджуєте. Докази підтверджують, що заходи фактично ефективно функціонують. Під час аудитів аудитори вибірково перевіряють заходи з вашої SoA та запитують відповідні докази.

SoA vs. Політики та процедури

Політики та процедури надають детальні інструкції щодо впровадження контрольних заходів. SoA узагальнює на високому рівні, які заходи існують та як вони працюють.

Як аудитори використовують SoA

Аудит етапу 1 (перевірка документації)

Аудитори перевіряють, чи є ваша SoA повною (розглянуто всі 93 контрольні заходи), логічно структурованою та узгодженою з вашою оцінкою ризиків. Вони перевіряють, чи мають сенс обґрунтування виключень.

Аудит етапу 2 (перевірка впровадження)

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

Причини невідповідностей

Поширені причини, через які аудитори фіксують невідповідності, пов'язані з SoA:

• Контрольні заходи позначені як "включені", але фактично не впроваджені
• Виключення без обґрунтування
• SoA не відображає фактичні результати оцінки ризиків
• Відсутні контрольні заходи (менше 93 зазначено)
• Описи реалізації занадто розпливчасті для перевірки

Ведення SoA з часом

Щорічні оновлення оцінки ризиків

Коли ви проводите планові переоцінки ризиків, переглядайте SoA, щоб визначити, чи залишаються вибрані контрольні заходи доречними. Нові ризики можуть потребувати раніше виключених заходів.

Організаційні зміни

Оновлюйте SoA, коли:

• Впроваджується нова технологія (можуть знадобитися нові технічні заходи)
• Змінюється бізнес-модель (наприклад, перехід до хмари змінює фізичні заходи)
• Географічне розширення вводить нові регуляторні вимоги
• Злиття або поглинання змінюють профіль ризиків

Перегляди, спричинені інцидентами

Після значних інцидентів безпеки перегляньте, чи були існуючі контрольні заходи ефективними або чи слід впровадити додаткові заходи (раніше виключені).

Наглядові аудити

Аудитори перевірятимуть під час щорічних наглядових аудитів, чи підтримується SoA в актуальному стані. Докази регулярного перегляду демонструють, що ваша СУІБ активна, а не залишена після сертифікації.

SoA та кастомізація контрольних заходів

Стандарт дозволяє адаптацію

ISO 27001 дозволяє організаціям впроваджувати контрольні заходи по-різному залежно від розміру, складності та ризиків. Ваша SoA повинна відображати вашу специфічну реалізацію, а не загальний шаблон.

Додаткові заходи понад Додаток A

Якщо ваша оцінка ризиків виявляє ризики, які не адекватно усуваються 93 стандартними заходами, ви можете впровадити додаткові заходи. Перелічіть їх у вашій SoA або додатковому документі.

Важливість пропорційності

Реалізація "A.6.3 Навчання з питань інформаційної безпеки" компанією з 10 співробітниками відрізнятиметься від реалізації в компанії з 10 000 співробітників. Обидві можуть бути відповідними, якщо відповідають контексту та ефективно знижують ризики.

Пов'язані поняття

• Контрольні заходи Додатка A - 93 заходи безпеки, які повинна розглядати ваша SoA
• Оцінка ризиків - Процес, що визначає вибір контрольних заходів у вашій SoA
• Обробка ризиків - Впровадження контрольних заходів, визначених у вашій SoA
• Контрольний захід - Заходи безпеки, які ви обираєте у вашій SoA
• Як розпочати впровадження ISO 27001 за допомогою ШІ

Отримання допомоги

Прискорте створення SoA за допомогою ISMS Copilot. Генеруйте кастомізовані описи реалізації, перевіряйте ваші обґрунтування на відповідність результатам оцінки ризиків та переконайтеся, що всі 93 контрольні заходи належним чином розглянуто.