Основна частина стандарту відповідає на питання «як керувати захистом». Додаток A відповідає на зовсім інше: «що саме зробити». Це нормативний список контролів, з якого організація бере потрібні під свої ризики — і лише їх. Розберемо, що всередині, як читаються номери, чому 93 позиції не дорівнюють 93 обов'язковим справам і яка тут роль супутньої настанови. Загальний устрій стандарту розібрано окремо — у матеріалі про структуру документа.
Додаток A 27001:2022: що всередині
У чинній редакції список містить 93 контролі, згруповані в чотири теми:
- Організаційні (розділ 5) — 37 позицій. Політики, ролі й відповідальність, класифікація інформації, робота з постачальниками, реагування на інциденти.
- Людські (розділ 6) — 8 позицій. Перевірка кандидатів, умови трудового договору, обізнаність і навчання, дисциплінарний процес, віддалена робота.
- Фізичні (розділ 7) — 14 позицій. Периметр, доступ до приміщень, захист обладнання, носії, чистий стіл і чистий екран.
- Технологічні (розділ 8) — 34 позиції. Права доступу, криптографія, журнали, резервні копії, розробка й тестування.
Звідси й читання номерів: 8.25 — це двадцять п'ятий пункт технологічної теми, а 5.7 — сьомий пункт організаційної. Жодної ієрархії всередині номера немає: це просто порядковий запис, а не рівень важливості.
ISO 27001: вимоги й заходи — це різні речі
Формально в ISO 27001 Додаток A має статус нормативного: він частина стандарту, а не довідкова вставка наприкінці. Але це не робить усі 93 позиції обов'язковими.
Обов'язкове — інше. Розділи 4–10 вимагають, щоб організація оцінила ризики, обрала спосіб їх обробки й обґрунтувала свій вибір. А список A працює як фінальна звірка: ви проходите по ньому й переконуєтеся, що нічого потрібного не проґавили.
Звідси поворот, про який зазвичай мовчать: список не вичерпний. Якщо ваш ризик потребує контролю, якого в стандарті немає, ви розробляєте його самі. Це не порушення, а прямо передбачений сценарій. Модель «беремо тільки те, що написано в таблиці» — вигадка консультантів, а не вимога.
Мета важливіша за інструмент
У редакції 2022 в кожного контролю з'явився окремий рядок «призначення» — навіщо він узагалі потрібен. Це не формальність: перевіряють саме досягнення мети, а не наявність конкретної програми.
Різниця відчутна на практиці. Питання звучить не «чи стоїть у вас антивірус», а «як ви не даєте шкідливому коду виконатися». Відповіддю може бути антивірус, може — білий список програм, може — ізольовані робочі місця. Стандарт свідомо не називає постачальників і технологій: він фіксує результат, а шлях до нього обираєте ви. Тому дві однаково сертифіковані компанії можуть мати геть різні технічні рішення.
Як контроль виглядає в житті: п'ять прикладів
- Звільнений працівник досі має доступ. Організаційний контроль: права відкликають у день звільнення. Доказ на аудиті — заявка з датою й відміткою про виконання.
- Підрядник працює з вашою базою. Той самий рівень: безпекові умови прописані в договорі, разом із правом на перевірку. Доказ — підписаний договір і акт перевірки.
- Ноутбук залишили в таксі. Технологічний контроль: диск зашифровано, пристрій можна віддалено заблокувати. Доказ — звіт системи керування пристроями.
- Лист «від бухгалтерії» з посиланням. Людський контроль: навчання й тренувальні розсилки. Доказ — журнал навчань і частка тих, хто клікнув.
- Стороння людина в серверній. Фізичний контроль: вхід за перепусткою, журнал проходів, відеоспостереження. Доказ — власне записи проходів.
Схема одна й та сама: ризик → контроль → доказ. Якщо третього елемента немає, аудитор вважає, що немає й другого.
Ланцюжок від ризику до SoA
Впровадження ISO 27001 починається не з Додатка A, а з питання «що ми взагалі захищаємо». Порядок дій такий:
- Реєстр активів — що є цінного: дані, системи, люди, приміщення. Практика — на сторінці реєстру інформаційних активів.
- Оцінювання ризиків — що з цим може статися і наскільки боляче буде. Методику дає ISO 27005.
- Рішення щодо кожного ризику — прийняти, уникнути, передати (наприклад, застрахувати) чи знизити.
- Вибір контролів — лише для тих ризиків, які вирішили знижувати.
- Звірка зі списком A — чи не пропустили чогось очевидного.
- Фіксація вибору — Заява про застосовність.
У проєкті ISO 27001 документація не самоціль, але Заява про застосовність (SoA) — виняток: це перший папір, який відкриває аудитор. Навпроти кожної з 93 позицій там стоїть відповідь: застосовна чи ні, чому саме так і в якому стані реалізація. Виключити контроль можна — але з поясненням, а не мовчки. Детально — на сторінці Заява про застосовність.
ISO 27002 перелік заходів не змінює, а пояснює
Плутанина між двома документами — найчастіша в темі. Різниця проста:
- Список A називає контроль і його мету: чого треба досягти.
- 27002 дає настанову: як цього досягти — з варіантами реалізації, поясненнями й застереженнями.
Сертифікують за 27001; другий текст у сертифікаті не згадують узагалі. Тому купувати обидва варто лише тоді, коли ви справді будуєте систему, а не заповнюєте таблицю для тендера.
Що виключають найчастіше
Виключень зазвичай менше, ніж очікують. Організаційні й людські контролі застосовні майже всім: політики, ролі, обізнаність, реагування на інциденти потрібні будь-якій компанії. Тож у Заяві про застосовність відпадає переважно те, чого у вас фізично немає:
- власна розробка — якщо ви не пишете коду й не замовляєте його;
- фізичний периметр і серверна — якщо вся інфраструктура орендована;
- хмарні сервіси — якщо все працює на власному обладнанні.
Формулювання «незастосовно, бо в нас цього немає» аудитора влаштовує. Формулювання «незастосовно, бо це дорого» — ні: вартість не скасовує ризику, вона лише змінює спосіб його обробки.
Що змінилося в редакції 2022
Перехід від 114 позицій до 93 — це не «скоротили роботу». Двадцять чотири старі контролі об'єднали, п'ятдесят вісім оновили, ще одинадцять додали з нуля:
- 5.7 — розвідка загроз;
- 5.23 — безпека при використанні хмарних сервісів;
- 5.30 — готовність ІКТ до безперервності бізнесу;
- 7.4 — моніторинг фізичної безпеки;
- 8.9 — керування конфігураціями;
- 8.10 — видалення інформації;
- 8.11 — маскування даних;
- 8.12 — запобігання витоку даних;
- 8.16 — моніторинг активності;
- 8.23 — вебфільтрація;
- 8.28 — безпечне кодування.
Самі новачки показують, куди зсунувся ландшафт за десять років: хмара, дані, спостережуваність. Технічний бік захисту розібрано окремо — шифрування, копії, вразливості; безпечну розробку — у матеріалі про контроль 8.25.
Атрибути: інструмент, який майже ніхто не використовує
У редакції 2022 кожен контроль отримав п'ять атрибутів. Це не вимога, а спосіб перегрупувати таблицю під свою логіку:
- тип — превентивний, детективний чи коригувальний;
- властивість — конфіденційність, цілісність, доступність;
- концепція — ідентифікувати, захистити, виявити, зреагувати, відновити;
- операційна спроможність — до якої функції належить (керування активами, безпека застосунків тощо);
- домен — врядування, захист, оборона, стійкість.
Що це дає на практиці? Можна показати керівництву зріз «чому ми запобігаємо, а що лише виявляємо» — і побачити перекіс, якщо всі гроші пішли в запобігання, а виявляти інциденти нічим. Або зіставити свою таблицю з іншим фреймворком, не переписуючи її з нуля. Користуватися атрибутами ніхто не зобов'язує — саме тому про них і забувають.
Три помилки, які видно на аудиті
Скачаний шаблон замість власного вибору. Формулювання «незастосовно» без прив'язки до конкретного ризику розсипається за два уточнювальні питання. Аудитор питає не «чи є документ», а «звідки взялося це рішення».
«Зробимо всі 93». Дорого, довго й безглуздо. Контроль, який не закриває жодного вашого ризику, — це витрата без результату, і вона ще й тягне за собою супровід: перегляд, навчання, докази.
Контроль лише на папері. Політику написали, а в реальності її ніхто не бачив. Перевіряють докази, а не наміри: журнали, записи, налаштування, підписи. Опора для всієї конструкції — політика інформаційної безпеки.