Statement of Applicability (SoA) часто сприймають як формальний документ “для аудитора” - список зі 93 контролів Annex A, де навпроти кожного стоїть галочка “застосовується / не застосовується”. На практиці це помилка, яка потім боляче виринає на сертифікаційному аудиті: SoA - не самостійний артефакт, а вихідна точка ланцюжка, який іде від активів через ризики до конкретних контролів. Якщо цей ланцюжок розірваний, SoA перетворюється на список побажань, а не на робочий документ ISMS. Я точно це знаю, бо пройшов еволюцію сприймання Заяви Про Застовність від формалізації до робочого інструменту. За це дякую як і курсам, на яких був, так і дійсно сертифікаційним аудитам, на яких аудитори задавали правильні питання :)

Ланцюжок: активи → ризики → контролі → SoA

Логіка стандарту (положення 6.1.2 та 6.1.3) вибудовує чіткий причинно-наслідковий зв’язок:

  1. Активи - інформаційні активи, які потрібно захищати: дані, системи, процеси, люди. Без інвентаризації активів немає предмету, до якого можна прив’язати ризик і, відповідно, ми не будемо знати, що ми маємо захищати.
  2. Ризики - оцінка ризиків проводиться відносно конкретних активів: які загрози та вразливості на них впливають, яка ймовірність і наслідки. Ризик “абстрактно існує” не буває - він завжди прив’язаний до активу (або групи активів/процесу). Ризик це те, від чого ми буде захищати наші активи.
  3. Контролі - обираються в процесі обробки ризиків як спосіб знизити ризик до прийнятного рівня. Тут ISO 27001 вимагає звірити обраний набір контролів з Annex A (Reference Control Set) - не для того, щоб обмежити вибір, а щоб перевірити повноту: чи не пропустили щось?
  4. SoA - формалізує результат: для кожного з контролів Annex A фіксує, чи застосовується він, чи впроваджений, і головне - чому. Саме так - треба пояснити не тільки, чому контроль (захід з безпеки) НЕ застосовується, але і чому він застосовується. Це може бути за результатами оцінки ризиків, вимоги законодавства або найкращі практики тощо.

Якщо в організації SoA (або ЗпЗ українською, але, відверто кажучи, мені не дуже подобається) існує окремо від реєстру ризиків - наприклад, скопійований з шаблону “типовий набір контролів для нашої галузі” - цей ланцюжок розірваний з самого початку. Контроль в SoA без прив’язки до конкретики - це фактично контроль, ефективність якого неможливо оцінити: незрозуміло, що саме він мав знизити, а отже, і виміряти це неможливо.

Чому обґрунтування в SoA - це не бюрократія

Стандарт (6.1.3d) прямо вимагає, щоб SoA містив обґрунтування для кожного включеного контролю і, окремо, обґрунтування для кожного виключеного контролю Annex A. Це не проформа, а три практичні речі одночасно:

  • Відслідковуванність. Обґрунтування - це посилання назад на ризик (або регуляторну вимогу, договірне зобов’язання, бізнес-рішення), який контроль покриває. Аудитор чи новий співробітник, дивлячись на SoA, повинен розуміти звідки взявся цей контроль, а не просто що він існує.

  • Захист від “театру заходів безпеки”. Тут у нас WAF, бо продавани AWS скзаали без цього ніяк, на всіх хостах у нас стоїть CrowdStrike та CarbonBlack, бо нам запропонували 85% знижки. А ще девопс був на конференції і сказав, що зараз обов’язково треба поруч із Nagios/Icinga додати ще Cloudwatch агента. Це все буде збиратись через Prometheus та відправлятись в дві різні TSDB, тому що однієї з реплікацією на декілька регіонів недостатньо. Я можу довго фантазувати, сам таким був колись. ResumeDrivenDevelopment :) Без обґрунтування легко накопичити контролі, які нічого конкретного не закривають - вони є, бо “так прийнято” або “в минулому шаблоні було”, або “прикольно було спробувати нову тулу”. Обов’язкове обґрунтування змушує на кожен контроль відповісти: який ризик він знижує і як я це перевірю. А ще може зекономити бюджет.

  • Керованість при зміні ризиків. Коли ризик переоцінюється (з’явилась нова загроза, змінився актив, ризик закрили) - обґрунтування в SoA підказує, які контролі варто переглянути. Без цього зв’язку зміна в реєстрі ризиків ніяк не відображається на SoA, і документи розходяться.

Це ж стосується виключених контролів: “цей контроль не застосовується, бо в нас немає власної інфраструктури розробки” - конкретне, перевірюване твердження. “Не застосовується” без пояснення - перше, до чого чіпляється сертифікаційний аудитор, і справедливо: без обґрунтування неможливо відрізнити свідоме рішення від того, що про контроль просто забули.

Практичний висновок

SoA варто вести не як окремий документ у стилі “заповнили один раз перед аудитом” (каюсь, так і робив колись), а як похідну від живого реєстру активів і ризиків - з реальним посиланням “цей контроль → цей ризик → цей актив” для кожного рядка.