Що таке межі ISMS у ISO 27001?
Межі ISMS визначають кордони та застосовність вашої системи управління інформаційною безпекою. Вимагається стандартом ISO 27001:2022, пункт 4.3, вони...
Огляд
Межі ISMS визначають кордони та застосовність вашої системи управління інформаційною безпекою. Вимагається стандартом ISO 27001:2022, пункт 4.3, вони точно вказують, які частини вашої організації, які локації, які системи та які процеси охоплюються ISMS — і, що не менш важливо, що виключається.
Межі є фундаментальним документом, який формує всі наступні дії ISMS, від оцінки ризиків до впровадження заходів контролю та підготовки до аудиту.
Межі ISMS на практиці
Ваші межі ISMS повинні бути задокументовані та враховувати:
- Зовнішні та внутрішні питання, визначені в пункті 4.1 (бізнес-контекст, регуляторні вимоги, загрози)
- Вимоги зацікавлених сторін з пункту 4.2 (клієнти, регулятори, партнери)
- Інтерфейси та залежності з іншими організаційними видами діяльності
Межі повинні бути доступні зацікавленим сторонам і зазвичай надаються клієнтам, аудиторам та органам сертифікації.
Ваші межі визначають, які заходи контролю з Додатка A застосовуються. Широкі межі означають більше активів для захисту та більше заходів контролю для впровадження; вужчі межі зменшують складність, але можуть обмежити цінність для бізнесу.
Компоненти меж ISMS
Організаційні кордони
Визначте, які бізнес-підрозділи, відділи або юридичні особи включені.
Приклад (повна організація): "Ця ISMS застосовується до всіх операцій корпорації Acme, включаючи головний офіс, регіональні офіси та віддалених працівників."
Приклад (конкретний підрозділ): "Ця ISMS охоплює підрозділ IT-послуг корпорації Acme, за винятком виробничих та роздрібних операцій."
Фізичні локації
Вкажіть, які географічні об'єкти або приміщення охоплюються.
Приклад: "Межі ISMS включають наш основний дата-центр у Франкфурті, Німеччина; корпоративні офіси в Парижі, Франція; та всі домашні офіси віддалених працівників у межах ЄС."
Процеси та види діяльності
Визначте, які бізнес-процеси підпадають під дію ISMS.
Приклад: "ISMS охоплює розробку програмного забезпечення, операції з хмарною інфраструктурою, обробку даних клієнтів, технічну підтримку та управління IT-послугами. Виключаються системи нарахування заробітної плати HR, які управляються третьою стороною."
Інформаційні активи
Визначте типи інформації та систем, що захищаються ISMS.
Приклад: "ISMS захищає персональні дані клієнтів, власний вихідний код, фінансові записи, інформацію про співробітників та всю підтримуючу IT-інфраструктуру (мережі, сервери, бази даних, SaaS-додатки)."
Виключення та обґрунтування
Чітко вкажіть, що НЕ включено, та поясніть чому.
Приклад: "ISMS не поширюється на виробничий завод у Шанхаї, оскільки він працює за окремою системою управління якістю ISO 9001 з власними заходами інформаційної безпеки, що контролюються місцевою дочірньою компанією."
Виключення повинні бути обґрунтовані та не можуть ставити під загрозу вашу здатність досягати запланованих результатів ISMS або відповідати законодавчим/регуляторним вимогам. Аудитори ретельно перевірятимуть необґрунтовані виключення.
Визначення меж: ключові аспекти
Бізнес-контекст (пункт 4.1)
Узгоджуйте межі зі стратегічними цілями, ризиками та вимогами відповідності:
- Які ваші критичні бізнес-процеси?
- Які регуляторні вимоги застосовуються (GDPR, HIPAA, PCI DSS)?
- Які загрози та можливості впливають на вашу організацію?
Вимоги зацікавлених сторін (пункт 4.2)
Переконайтеся, що межі враховують потреби стейкхолдерів:
- Чи вимагають клієнти сертифікацію ISO 27001 для певних послуг?
- Чи передбачають контракти забезпечення безпеки певних даних або систем?
- Чи існують законодавчі зобов'язання щодо захисту певних типів інформації?
Підхід, заснований на ризиках
Визначайте пріоритети для зон високого ризику:
- Які активи, у разі компрометації, завдадуть найбільшої шкоди?
- Де ваші найбільші вразливості в інформаційній безпеці?
- Які процеси обробляють найбільш конфіденційні дані?
Практичність та ресурси
Збалансуйте повноту охоплення з можливістю впровадження:
- Чи є у вас ресурси для впровадження заходів контролю в усій організації?
- Чи є поетапний підхід більш реалістичним (почніть з основних послуг, розширюйте пізніше)?
Почніть з вужчих меж, зосереджених на критичних системах та процесах з високою цінністю. Ви можете розширити межі пізніше, коли ваша ISMS стане зрілішою, демонструючи постійне вдосконалення.
Поширені шаблони меж
Межі на основі продукту/послуги
"ISMS застосовується до проектування, розробки, розгортання та підтримки нашої SaaS-платформи управління взаємовідносинами з клієнтами (CRM)."
Найкраще підходить для: Компаній-розробників програмного забезпечення, постачальників послуг, окремих продуктових ліній.
Межі на основі локації
"ISMS охоплює всю діяльність з інформаційної безпеки в нашій європейській штаб-квартирі та пов'язаній з нею хмарній інфраструктурі."
Найкраще підходить для: Організацій з чіткими регіональними операціями або кордонами відповідності (наприклад, GDPR в ЄС).
Межі на основі підрозділу
"ISMS застосовується до відділу інформаційних технологій та всіх систем, мереж і даних, якими він керує."
Найкраще підходить для: Організацій, які починають впровадження ISMS або мають федеративне управління безпекою.
Межі для всієї організації
"ISMS охоплює всі операції, об'єкти, співробітників та інформаційні активи корпорації Acme у всьому світі."
Найкраще підходить для: Зрілих організацій, які прагнуть до всеохопного управління безпекою або демонструють корпоративну відданість.
Формат опису меж
Хоча ISO 27001:2022 не вимагає конкретного формату, ефективні описи меж зазвичай дотримуються такої структури:
- Вступ: Назва організації та мета ISMS
- Включення: Бізнес-підрозділи, локації, процеси, системи, типи даних, що охоплюються
- Виключення: Що не охоплюється та чому
- Застосовність: До кого застосовується ISMS (співробітники, підрядники, партнери)
- Інтерфейси: Зв'язки з іншими системами управління або зовнішніми сторонами
- Затвердження: Затверджено вищим керівництвом із зазначенням дати
Приклад опису меж
"ISMS Acme Cloud Services застосовується до проектування, розробки, експлуатації та підтримки нашої багатоарендної платформи хмарного сховища, включаючи всю пов'язану інфраструктуру (дата-центри у Франкфурті та Дубліні), персонал (команди інженерів, операцій, підтримки) та інформаційні активи (дані клієнтів, код платформи, корпоративні IT-системи). Межі включають віддалених співробітників по всьому світу. Виключено: сторонню обробку платежів, що здійснюється Stripe за їхньою власною сертифікацією ISO 27001. Ця ISMS відповідає вимогам ISO 27001:2022, GDPR та SOC 2 Type II."
Використовуйте ISMS Copilot для створення опису меж ISMS, адаптованого до вашої організації, визначення відповідних включень та виключень або зіставлення вимог зацікавлених сторін з елементами меж.
Перегляд та оновлення меж
Ваші межі не є статичними. Переглядайте та оновлюйте їх:
- Під час аналізу з боку керівництва (пункт 9.3) через заплановані проміжки часу
- Коли відбуваються значні зміни (злиття, нові послуги, зміни в регулюванні)
- Якщо внутрішні аудити або інциденти виявляють прогалини в охопленні
- У рамках постійного вдосконалення для розширення захисту
Документуйте зміни в межах, отримуйте схвалення вищого керівництва та повідомляйте про оновлення зацікавленим сторонам.
Вплив меж на заходи контролю
Ваші межі безпосередньо визначають:
- Кордони оцінки ризиків: Які активи та загрози оцінювати (пункт 6.1.2)
- Застосовні заходи контролю: Які заходи контролю з Додатка A є релевантними (пункт 6.1.3)
- Заяву про застосовність: Що включати до SoA
- Межі аудиту: Що оцінюватимуть органи сертифікації
- Вимоги до ресурсів: Бюджет, персонал, інструменти, необхідні для впровадження
Поширені помилки, яких слід уникати
- Надто широкі межі для наявних ресурсів, що призводить до неповного впровадження
- Надто вузькі межі, які виключають критичні системи або дані
- Нечіткі формулювання, що роблять кордони незрозумілими
- Виключення зон високого ризику без обґрунтування
- Невідповідність меж вимогам клієнтів або регуляторів
- Неоновлення меж при змінах у бізнесі
- Відсутність схвалення з боку вищого керівництва
Пов'язані терміни
- ISMS – Те, для чого межі визначають кордони
- Interested Parties – Вимоги яких інформують визначення меж
- Risk Assessment – Проводиться в межах визначених кордонів
- Statement of Applicability – Заходи контролю обираються на основі меж