Стандарт можна прочитати від першої сторінки до останньої й так і не зрозуміти головного: усе, що в ньому написано, обертається навколо однієї речі — керованої системи. Розберемо, чим вона є насправді, якими мають бути її цілі, чи справді обов'язковий славнозвісний цикл поліпшення і як усе це стикується з сусідніми стандартами. Устрій самого документа описано окремо — у матеріалі про структуру стандарту.
ISMS: що це таке простими словами
Абревіатура розшифровується як Information Security Management System — система управління інформаційною безпекою. Українською її звично скорочують до СУІБ.
І одразу головне непорозуміння: це не програма, не відділ і не тека з документами. Це спосіб, у який компанія ухвалює рішення про захист своєї інформації — і перевіряє, чи вони спрацювали.
Аналогія, яка добре лягає: СУІБ — не замок на дверях. Це служба, яка вирішує, на які двері ставити замки, регулярно перевіряє, чи вони не заіржавіли, і замінює їх, коли змінився будинок.
ISO 27001, ISMS і СУІБ: одне й те саме?
Плутанина в назвах коштує людям годин на перемовинах, тож розкладемо:
- ISMS і СУІБ — це одне й те саме, англійська абревіатура та її український відповідник.
- Стандарт — це вимоги до такої системи. Система первинна, документ — вторинний.
- Сертифікат підтверджує, що система відповідає вимогам. Мати систему без сертифіката можна. Мати сертифікат без системи — ні.
Звідси й помилка, яку чути в перемовинах: «ми хочемо купити СУІБ». Купити її не вийде — як не вийде купити бухгалтерію. Купують інструменти, консультації й навчання; систему вибудовують самі. Практичний бік описано на сторінці впровадження.
Цілі ISMS: чому «підвищити рівень безпеки» — не мета
Стандарт очікує від цілей конкретики. Вони мають бути узгоджені з політикою, враховувати результати оцінювання ризиків, бути вимірюваними, доведеними до людей, задокументованими — і за ними мають стежити.
Порівняйте.
Так не можна: «підвищити рівень інформаційної безпеки». Тут немає числа, строку, відповідального й способу заміру. На аудиті така формула не витримує жодного уточнювального запитання.
Так можна: «скоротити середній час усунення критичних хиб із 30 до 7 днів до кінця року; відповідальний — керівник ІТ; замір щомісяця за реєстром знахідок».
Ознака доброї мети проста: через рік ви зможете сказати «досягли» або «не досягли» — і ніхто не сперечатиметься. Якщо ж відповідь звучить як «ну, загалом стало краще», це була не мета, а побажання.
Цикл поліпшення: PDCA чи не PDCA
Майже в кожній статті ви прочитаєте, що система «будується на циклі PDCA». Це напівправда, і варто знати, у чому саме.
Починаючи з редакції 2013 року стандарт не вимагає PDCA явно. Він вимагає іншого — постійного поліпшення, і залишає за вами вибір моделі. PDCA лишається найзручнішою картою, але це саме карта, а не обов'язок.
Структура розділів справді лягає на неї природно:
- Плануй — контекст, лідерство, планування, ресурси (розділи 4–7).
- Виконуй — процеси, оцінювання й обробка ризиків у робочому режимі (розділ 8).
- Перевіряй — моніторинг, вимірювання, внутрішні аудити, аналіз з боку керівництва (розділ 9).
- Дій — поліпшення й робота з невідповідностями (розділ 10).
І тут — деталь редакції 2022, на якій сипляться навіть досвідчені. Пункти десятого розділу поміняли місцями: поліпшення тепер 10.1, а невідповідності й коригувальні дії — 10.2. Це не косметика. Аудитор перевіряє обидва, і журнал, у якому записано лише «зламалося — виправили», закриває другий пункт і не закриває перший. Поліпшення — це коли ви подивилися на процес, який працює нормально, і зробили його кращим.
Ще одне нововведення 2022 року — окремий пункт 6.3 про планування змін. Зміни в системі більше не можна вносити «на ходу».
Сфера застосування: найдорожче рішення на старті
Межу системи проводять на самому початку — і саме тут роблять найдорожчі помилки.
Візьмете забагато — проєкт потоне: доведеться описувати процеси, які до захисту інформації мають дуже опосередкований стосунок, і команда вигорить ще до першого внутрішнього аудиту. Візьмете замало — сертифікат виявиться майже марним: замовник прочитає рядок зі сферою й побачить, що перевіряли зовсім не той підрозділ, з яким він працює.
Робоче правило: межу проводять там, де закінчується ваш реальний контроль. Якщо ви не можете змінити правила в якомусь відділі, не тягніть його всередину на першому колі — краще розширити межу наступного року, ніж провалити перший аудит.
З чого складається система
- Контекст і сфера застосування — що саме охоплено, а що лишилося поза межами.
- Ролі й відповідальність — хто ухвалює рішення, хто виконує, хто перевіряє.
- Оцінювання ризиків — основа для всього іншого; методику дає ISO 27005.
- Заходи захисту — обрані під ризики контролі Додатка A.
- Документація — політики, процедури, реєстри: склад описано окремо.
- Обізнаність і навчання — бо контроль, про який ніхто не знає, не працює.
- Моніторинг, аудити та аналіз з боку керівництва — механізм зворотного зв'язку.
- Поліпшення — те, заради чого існують попередні пункти.
ISO 27001, безперервність бізнесу і ISO 22301
Ці дві системи впроваджують у парі так часто, що їх плутають. Різниця в питанні, на яке вони відповідають:
- перший стандарт питає: чи захищена інформація?
- ISO 22301 — BCMS, система управління безперервністю діяльності — питає інше: чи працюємо ми, коли все пішло не так?
Стикуються вони у двох конкретних місцях Додатка A: пункт 5.29 — захист інформації під час порушення роботи, і пункт 5.30 — готовність ІКТ до відновлення. Саме там закінчується одна система й починається друга.
У сусіда свій інструментарій, якого в нашому стандарті немає: аналіз впливу на діяльність, допустимий час відновлення й допустимий обсяг втрачених даних. Зате каркас розділів 4–10 у них спільний — тож на практиці роблять одну інтегровану систему: один внутрішній аудит, один аналіз керівництва, одна робота з невідповідностями. Детальніше — на сторінці про безперервність діяльності.
Хмара, ISO 27001 і поділ відповідальності
Переїзд до провайдера не скасовує системи — він змінює межі. Хмарні сервіси входять у сферу застосування, а відповідальність за них ділиться: інфраструктура на боці постачальника, налаштування, права доступу й копії — на вашому. Тому в реєстрі ризиків з'являється окремий блок про постачальника, а в договорі — умови щодо повідомлень про інциденти. Вимоги, які тут допомагають, зібрано в ISO 27017.
Три ознаки мертвої системи
- Документи востаннє оновлювали напередодні минулого аудиту. Жива система лишає сліди щомісяця, а не раз на рік.
- У цілей немає цифр. Дивіться розділ вище: без числа й строку це не мета.
- Реєстр ризиків не змінювався рік — хоча компанія за цей час найняла двадцять людей, переїхала в хмару й запустила новий продукт. Ризики змінилися, реєстр — ні.