Imperium Certific

Сертифікація СУІБ за ISO 27001: як орган оцінює зрілість системи

Як орган сертифікації оцінює зрілість СУІБ: цілі ISMS за розділом 6.2, ознаки живої системи, поділ відповідальності в хмарі та зв'язок ISO 27001 з ISO 22301.

Дві компанії з однаково оформленими теками документів проходять перевірку по-різному. Перша відповідає на питання аудитора записами за минулі місяці, друга — поясненнями намірів. Формальної шкали зрілості в стандарті немає, проте досвідчена аудиторська група розрізняє ці стани за перші дві години роботи. Розповідаємо, за якими ознаками.

ISMS — що це для органу сертифікації

Абревіатура розшифровується як information security management system, українською — система керування інформаційною безпекою, СУІБ. Обидва скорочення означають одне й те саме, тож питання «ISO 27001 ISMS чи СУІБ» — суто термінологічне.

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

Звідси й предмет перевірки. Орган підтверджує не захищеність інфраструктури, а керованість: наявність рішень, підстав під ними й доказів виконання.

Цілі ISMS: як їх читає аудитор

Розділ 6.2 вимагає, аби цілі були вимірними, узгодженими з політикою, доведеними до відповідальних осіб і переглянутими за потреби. На перевірці ця вимога перетворюється на чотири прості питання: у чому вимірюємо, хто відповідальний, до якої дати, звідки беремо цифру.

Слабке формулювання Що спитає аудитор Робочий варіант
Підвищити рівень захищеності Як зрозуміти, чи підвищили? Скоротити середній час усунення критичних слабких місць із 30 до 7 днів до кінця року
Навчити персонал Кого, чого і з якою перевіркою? Провести інструктаж для 100 % нових працівників у перший тиждень; замір щокварталу
Зменшити кількість інцидентів З чого рахуємо базу? Скоротити повторні інциденти однієї категорії удвічі порівняно з минулим півріччям

Ознака робочої мети проста: через рік сторони без суперечок скажуть «досягнуто» або «ні». Якщо для відповіді потрібна дискусія — формулювання ще сире.

Другий шар перевірки — доля досягнутої мети. Зріла система свою мету закриває й ставить наступну. Система на папері рік у рік показує ті самі три рядки без жодної цифри.

Перші дві години перевірки

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

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

Жодне з прохань підготовки не потребує — налагоджена система відповідає без пауз.

Шість ознак живої системи

  • Реєстр ризиків рухається. Зʼявилися нові підрядники, сервіси, локації — і це видно в оцінюванні.
  • Невідповідності знаходить сама компанія. Внутрішні перевірки дають зауваження. Звіт без жодної знахідки за рік викликає більше сумнівів, ніж десяток дрібних.
  • Інциденти мають розбір причин. Не лише «відновили роботу», а й «чому стало можливим» із рішенням.
  • Аналіз з боку керівництва закінчується рішеннями. Протокол із термінами та відповідальними, а не констатація.
  • Постачальники в полі зору. Оцінювання зовнішніх сторін ведеться, а не згадується.
  • Люди знають своє. Власник процесу пояснює власними словами, як влаштована його ділянка, без підказок консультанта.

Жодна з ознак окремо рішення не визначає. Разом вони дають картину, за якою група розуміє, де копати глибше, а де достатньо вибірки.

Як змінюється перевірка від циклу до циклу

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

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

Ресертифікація третього року дивиться ширше — результативність за весь цикл, а не окремі епізоди. Саме тут стає видно, чи змінювалися цілі, чи закривалися ризики, чи компанія три роки поспіль показує одну й ту саму картину.

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

Хмара ISO 27001: чия відповідальність на перевірці

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

Три речі, які аудитор попросить показати:

  • договір або угоду про рівень послуг із зафіксованим розподілом обовʼязків;
  • ваші власні налаштування в панелі керування — права доступу, журнали, копії;
  • підтвердження, що чинність сертифіката провайдера перевірялася, а не приймалася на віру.

Найпоширеніша ілюзія — «копії робить провайдер». Копії робить той, хто це налаштував і перевірив відновлення. Для хмарних середовищ сферу зазвичай доповнюють механізмами 27017 і 27018 — окремий бланк при цьому не видається.

ISO 27001, безперервність бізнесу і суміжний напрям

У Додатку A є два механізми, які стосуються стійкості: 5.29 — захист інформації під час порушення роботи, 5.30 — готовність ІКТ до безперервності діяльності. Обидва перевіряються в межах звичайної процедури, і саме на них найчастіше зʼясовується, що план відновлення жодного разу не випробовували.

ISO 22301 BCMS — окрема система керування безперервністю діяльності, зі своїм інструментарієм: аналіз впливу на діяльність, цільовий час відновлення, допустима втрата даних. У межах перевірки за 27001 цей інструментарій не вимагається, хоча компанії, які його мають, проходять розділ стійкості помітно легше.

Важливий момент: сертифікація за 22301 — самостійна галузь акредитації. Наш поточний перелік напрямів опубліковано в каталозі послуг — перевіряйте його перед плануванням, бо галузі в органів різняться.

З чого починається зрілість

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

Ще один орієнтир — люди. Коли в межі потрапляє підрозділ, керівник якого дізнається про систему від аудитора, межу проведено неправильно.

Робочий орієнтир — межу проводять там, де закінчується реальний контроль компанії. Ділянка, якою ви не керуєте, всередині системи створює постійне джерело невідповідностей.

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

Плануєте перевірку? Подайте заявку — оцінимо готовність, узгодимо межі сфери застосування й розрахуємо обсяг робіт. Базові поняття зібрано в матеріалі сертифікація ISO 27001: що це і кому потрібна.

Часті запитання

Повернутися до новин