NIS2 та договори з постачальниками – які вимоги щодо кібербезпеки слід узгодити?

Від Mallbutiken · Дані перевірено 30 вересня 2026 р. · Приблизний час читання 9 хвилин

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

Що говорить закон про кібербезпеку щодо ланцюга поставок?

Шведський закон про кібербезпеку (2025:1506) набув чинності 15 січня 2026 року і впроваджує частини директиви NIS2. Для суб'єктів господарювання, на яких поширюється закон, заходи безпеки мають бути належними та пропорційними, базуватися на перспективі загальних ризиків і забезпечувати рівень безпеки, відповідний рівню ризику.

У розділі 2, параграфі 3 перераховано сфери, яких щонайменше мають стосуватися заходи безпеки. Серед них чітко зазначено безпеку в ланцюгу поставок, разом із, зокрема, управлінням інцидентами, безперервністю та кризовим управлінням, безпечними закупівлями та обслуговуванням, моніторингом заходів безпеки, кібергігієною, криптографією, контролем доступу та автентифікацією.

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

Почніть із критичності постачальника

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

Документуйте оцінку. Тоді буде легше обґрунтувати, чому до критичного постачальника висуваються ширші вимоги та частіший моніторинг, ніж до постачальника з обмеженим впливом. Для визначення того, як швидко має бути відновлена критична діяльність, ви можете використовувати BIA/аналіз впливу на бізнес.

10 сфер кібербезпеки для регулювання в договорах із постачальниками

1. Визначений рівень безпеки. Опишіть, які керівні вимоги, політики або зони контролю має виконувати постачальник і для якої частини послуги.
2. Ідентифікація та доступ. Регулюйте принципи прав доступу, привілейованих облікових записів, MFA, перевірок доступу та закриття облікових записів там, де це доречно.
3. Вразливості та патчинг. Вкажіть, як вразливості виявляються, пріоритезуються, усуваються та комунікуються.
4. Журналювання та відстежуваність. Визначте, які журнали потрібні, як довго вони зберігаються і як замовник може отримати відповідну інформацію в разі інциденту.
5. Інформація про інциденти. Вкажіть, коли і як постачальник має повідомляти замовника, яку інформацію потрібно надати та як відбуваються оновлення.
6. Безперервність та відновлення. Регулюйте резервне копіювання, відновлення, резервні процедури, тестування та відповідні значення RTO/RPO.
7. Субпідрядники. Визначте, яких критичних субпідрядників можна залучати, як повідомляти про їхню зміну та які вимоги слід поширювати далі в ланцюгу.
8. Верифікація. Вкажіть, яку документацію, результати аудиту, результати тестів чи інші докази замовник може використовувати для перевірки.
9. Зміни. Регулюйте суттєві технічні або організаційні зміни, що можуть вплинути на профіль ризику.
10. Вихід із відносин. Визначте, як припиняється доступ, як повертаються або видаляються дані та як здійснюється міграція без непотрібного розриву в безпеці або безперервності.

Інциденти: договір має підтримувати власне управління замовника

Коли постачальник виявляє інцидент, замовник повинен отримати інформацію достатньо швидко, щоб оцінити власний вплив і можливі зобов'язання щодо звітності. Тому уникайте розпливчастих формулювань, які лише кажуть, що постачальник інформує «за потреби».

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

Субпідрядники: визначте критичні залежності

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

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

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

Як відстежувати виконання вимог безпеки постачальника?

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

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

Сертифікація — це основа, а не вся оцінка

Сертифікація або зовнішній звіт можуть надати цінну інформацію, але перевірте обсяг. Які системи, місця та послуги охоплені? Чи є звіт актуальним? Чи є винятки або примітки? Чи відповідає він тому, що ви насправді купуєте?

Безперервність: договірна вимога має відповідати потребам бізнесу

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

Постачальник SaaS? Узгодьте додаток з безпеки з основним договором

Для хмарних послуг вимоги безпеки повинні працювати разом із SLA, підтримкою, даними, субпідрядниками, відповідальністю та виходом із відносин. Суперечливі додатки створюють нові ризики. Прочитайте, що має містити договір SaaS, і обов'язково вкажіть, який документ має пріоритет, якщо договірні документи містять різні положення.

Чек-лист перед укладанням договору з критичним постачальником

• Чи класифіковано постачальника на основі критичності та залежності?
• Чи ідентифіковано найважливіші системи, потоки даних та доступи?
• Чи є вимоги безпеки пропорційними та такими, що підлягають перевірці?
• Чи є чіткий контакт щодо інцидентів та вимоги щодо швидкої початкової інформації?
• Чи врегульовані субпідрядники та зміни в ланцюгу?
• Чи є вимоги щодо управління вразливостями та оновленнями (патчингом)?
• Чи можна протестувати резервне копіювання, відновлення та безперервність?
• Чи є розумний спосіб контролювати дотримання вимог?
• Чи заплановано вихід, повернення даних та припинення доступу?
• Чи узгоджено договір із GDPR/PUB, SLA та іншими відповідними додатками?

Потрібно структурувати роботу над NIS2?

Пакет NIS2 від Mallbutiken містить 15 інтегрованих шаблонів документів, зокрема для управління ризиками, інцидентами, безперервності, безпеки постачальників та додатку з безпеки до договору з постачальником. Постачається у форматах Word та PDF. Ціна в магазині: 199 шведських крон.

Переглянути пакет шаблонів NIS2

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

Чи підпадають усі постачальники під дію NIS2?

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

Чи достатньо вимагати ISO 27001?

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

Чи повинні всі постачальники отримувати однаковий додаток з безпеки?

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