Оцінка прогалин ISO 27001: етапи та результати

Оцінка прогалин за ISO 27001 зіставляє поточні контролі та документи компанії з вимогами розділів стандарту й набором контролів Додатка A, після чого видає пріоритезований план усунення недоліків. Вона готує компанію до сертифікаційного аудиту, але сама сертифікатом не є, і жодна оцінка не дає гарантії, що сертифікацію буде отримано.

Що таке оцінка прогалин за ISO 27001?

ISO/IEC 27001 — це міжнародний стандарт для системи управління інформаційною безпекою (СУІБ): задокументований, заснований на ризиках набір політик, процесів і контролів, який постійно підтримують і вдосконалюють, а не встановлюють один раз і назавжди. Сертифікат видає акредитований орган із сертифікації за результатами власних аудитів; сам стандарт купують в ISO, і саме його вимоги є тим, з чим зіставляють будь-яку оцінку.

Оцінка прогалин чесно відповідає на одне питання: наскільки організація сьогодні далека від виконання цих вимог? Вона переглядає те, що вже існує — документи, фактичну практику, технічні налаштування — і фіксує розбіжності як висновки щодо розділів стандарту (вимоги до системи управління містяться в розділах 4–10) та щодо набору контролів Додатка A, який у версії 2022 року налічує 93 референсних контролі, згрупованих за темами.

Три уточнення, які згодом зекономлять чимало непорозумінь:

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

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

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

Процес оцінювання

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

Таблиця A: крок | що відбувається | результат

Крок	Що відбувається	Результат
Визначення меж	Узгоджують межі СУІБ: які локації, підрозділи, системи та дані входять до неї і чому; визначають зацікавлені сторони та їхні вимоги	Опис меж з обґрунтуванням, готовий до повторного використання на аудиті Етапу 1
Аналіз документів	Читають наявні політики, процедури та записи й зіставляють їх із розділами 4–10 і Додатком A; перевіряють, чи описують документи реальність, а не бажане	Інвентаризація документів зі статусом кожного: наявний / частковий / відсутній, із зазначенням переглянутих доказів
Інтерв'ю	Спілкуються з людьми, які ведуть процеси — IT-відділ, кадри, операційний підрозділ, фінанси, керівництво — і порівнюють відповіді між ролями; суперечності між двома відділами теж є висновками	Нотатки інтерв'ю за кожним процесом із зафіксованими розбіжностями між практикою та документом
Технічні перевірки	Вибірково дивляться фактичні налаштування: списки доступу, журналювання, завдання резервного копіювання та докази відновлення, стан патчів, фізичний доступ — саме вибірково, а не пентест	Результати перевірок за кожною сферою контролю, з вибірками й датами, щоб результат можна було перевірити повторно
Оцінювання	Кожен висновок зважують за критичністю та трудовитратами; критичність випливає з ризику для організації, а не з місця контролю в Додатку A	Реєстр прогалин: розділ або контроль, поточний стан, висновок, критичність, рекомендований власник
Звіт і дорожня карта	Збирають висновки у звіт і визначають послідовність робіт: швидкі перемоги, структурні пункти та документи, які мають існувати до аудиту Етапу 1	Звіт про аналіз прогалин, дорожня карта усунення з пріоритетами, проєкт Заяви про застосовність

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

Результати робіт

Серйозну оцінку визначають чотири артефакти. Якщо в пропозиції не названо всі чотири, варто запитати чому:

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

Реєстр прогалин. Робоча база даних: кожен висновок із посиланням на розділ або контроль Додатка A, поточним станом, критичністю та пріоритетом. Саме на реєстрі проєкт працює далі — він перетворює звіт із поради на беклог із відповідальними.

Дорожня карта усунення. Висновки, вибудувані в план: що має існувати до аудиту Етапу 1, що належить до перших місяців роботи СУІБ, а що може зачекати. Порядок ураховує взаємозалежності — не можна перевіряти доступ щоквартально, поки немає списків доступу.

Проєкт Заяви про застосовність (SoA). Документ, який перелічує кожен контроль Додатка A, зазначає, чи він застосовний і чому, та описує, як його впроваджено. Проєкт SoA, підготовлений під час оцінки, — найбільша економія часу в сертифікаційному проєкті, бо інакше доведеться писати 93 рішення з чистого аркуша і в умовах дедлайну.

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

Чим оцінка не є

Точність у цьому питанні збереже вас від зайвих суперечок:

Це не сертифікат. Сертифікувати СУІБ може лише акредитований орган із сертифікації, який працює за ISO/IEC 17021 і власною акредитацією. Оцінка — це консультаційна робота; її висновки не мають жодної сили для органу сертифікації, і жоден результат оцінки не гарантує сертифікації — організація може пройти оцінку й усе одно не пройти аудит Етапу 2 через висновки, які аудитор зробить самостійно.

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

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

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

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

Підготовка до сертифікаційного аудиту

Справжня цінність оцінки проявляється в сертифікаційному проєкті, який іде за нею. Ось як вони пов'язані:

Етап 1 перевіряє документацію та межі: опис меж СУІБ, оцінювання ризиків та оброблення ризиків, політики, Заяву про застосовність, записи внутрішніх аудитів і аналізу з боку керівництва. Більшість висновків Етапу 1 — це відсутні або застарілі документи, а саме їх і виробляють аналіз документів та проєкт SoA в межах оцінки.

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

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

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

Типові прогалини

Висновки, які найчастіше повторюються в малих і середніх компаніях, приблизно за частотою появи:

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

Метод оцінювання ризиків. Або відсутній, або запозичений із шаблону без організаційного обґрунтування; аудитор із сертифікації спитає, як виявляли та обробляли ризики, і відповідь «це написав консультант» перевірки не витримає.

Управління постачальниками. Немає реєстру постачальників, які мають доступ до даних компанії, немає вимог безпеки в договорах із постачальниками, немає циклу перегляду. Для компаній, які працюють із партнерами з розробки, ця прогалина лягає прямо на договірні питання, розглянуті на сторінці IT-аутсорсингу.

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

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

Навчання з обізнаності. Одноразовий слайд на онбордингу замість регулярної програми із записами. Стандарт запитує, чи усвідомлюють люди свої обов'язки; відповіддю на це питання може стати датований список відвідувачів.

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

Як обрати постачальника

Три питання відділяють ретельну оцінку від дорогого огляду:

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

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

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

Два практичні моменти для компаній у Туреччині: з'ясуйте, чи працює оцінювач зі стандартами та органами сертифікації, знайомими клієнтам вашого цільового ринку, бо у вимогах замовників часто названо конкретні схеми; і підтвердьте робочу мову інтерв'ю та документів, бо висновки мають бути придатні для команд, які їх виправлятимуть. Чекліст для RFP щодо постачальників дає загальний метод оцінювання такої закупівлі, а сторінка IT-аудиту та консалтингу охоплює ширший консультаційний контекст.

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

Скільки триває оцінка прогалин?

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

Чи потрібен нам ISO 27001, щоб продавати?

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

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

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

Як оцінюють прогалини?

За критичністю та пріоритетом, причому критичність прив'язана до ризику для організації, а не до місця контролю в стандарті. Придатна оцінка пояснює себе сама: що станеться, якщо прогалину залишити, хто або що під загрозою й чого коштує її закрити. Оцінки, які лише розставляють пункти «високий/середній/низький» без пояснень, згодом породжують суперечки; оцінки з письмовим обґрунтуванням дають дорожню карту, за якою люди справді йдуть.

Чи може оцінка прогалин замінити аудит?

Ні. Внутрішній аудит і аналіз з боку керівництва — це зобов'язання всередині СУІБ, а сертифікаційний аудит належить акредитованому органу із сертифікації. Оцінка прогалин передує обом і допомагає з обома, але не має жодного аудиторського статусу — це та сама лінія «не сертифікат» вище, і будь-якого постачальника, який її розмиває, варто попросити пояснити письмово.

Частково перетинаються, але це не те саме. ISO 27001 — це стандарт системи управління для інформаційної безпеки, і захисту даних він торкається лише там, де контролі безпеки захищають персональні дані; KVKK і GDPR встановлюють юридичні обов'язки — правову підставу, права суб'єктів даних, повідомлення про порушення, правила передачі — які СУІБ може підтримувати, але самотужки не виконує. Багато компаній ведуть обидві програми зі спільними артефактами, а юридичні питання залишаються за кваліфікованим радником; обов'язки за KVKK/GDPR щодо постачальників і хостингу розглянуто на сторінці IT-аутсорсингу.

Джерела та стандарти

Сам стандарт — це ISO/IEC 27001, виданий ISO (https://www.iso.org); оцінювані вимоги — це розділи 4–10 і набір контролів Додатка A, який у версії 2022 року містить 93 референсних контролі. Сертифікацію проводять акредитовані органи із сертифікації, що працюють за ISO/IEC 17021; ця сторінка не заявляє жодних сертифікаційних тверджень.
Твердження про процес, результати та типові прогалини відповідають загальноприйнятій практиці проведення оцінок прогалин (узгодження меж, аналіз документів, інтерв'ю, технічний вибірковий контроль, реєстр прогалин із градацією за критичністю, дорожня карта усунення, проєкт Заяви про застосовність); жодних термінів, витрат чи відсотків успіху на цій сторінці немає.
Твердження про процес сертифікації (аудит документації на Етапі 1, аудит упровадження на Етапі 2, наглядові аудити) відповідають опублікованій рамці сертифікації цього стандарту; актуальні правила уточнюйте в обраному органі сертифікації.
Жодного твердження, що WorldwideTradeX має сертифікат ISO 27001 чи акредитацію, і жодної гарантії сертифікації на цій сторінці немає; обов'язки щодо захисту даних названо, але не тлумачено — застосовний режим уточнюйте в кваліфікованого радника.

Пов'язані сторінки

IT-аудит і консалтинг · Цифрова інфраструктура · IT-аутсорсинг із Туреччини · Чекліст RFP для постачальників · Запросити пропозицію