Договори с доставчици по NIS2 с доказателства по ISO 27001

07:40 е в понеделник. CISO на логистична платформа с облачни възможности отваря имейл от доставчик на управлявани услуги за откриване и реагиране. Съобщението е кратко, предпазливо и обезпокоително: доставчикът е открил подозрителен достъп до среда за поддръжка, използвана от няколко клиента. Подробностите са ограничени. Доставчикът обещава актуализация „веднага щом това е практически възможно“.

В 08:15 мениджърът по съответствието пита дали това може да задейства докладване по NIS2. В 08:40 отделът по снабдяване търси договора. В 09:10 секретарят на ръководния орган иска кратък доклад относно отчетността на ръководството. В 10:00 правният отдел пита дали договорът включва 24-часово уведомяване, права на одит, контроли за подизпълнители, достъп до доказателства, задължения за непрекъсваемост на дейността, връщане на данни и разпоредби за изтриване.

Никой не иска по време на реален инцидент да установи, че договорът с критичен доставчик съдържа само „разумни мерки за сигурност“.

Тук клаузите в договорите с доставчици по NIS2 престават да бъдат стандартен правен текст и се превръщат в оперативни контроли. За съществените и важните субекти управлението на доставчици вече е част от отчетността на ръководния орган, доказателствата за надзор, готовността за инциденти, увереността за клиентите, съответствието в областта на защитата на личните данни и планирането на устойчивостта. Подписаният договор не е достатъчен. Организацията трябва да докаже, че рисковете, свързани с доставчици, са идентифицирани, одобрени, третирани, наблюдавани и подкрепени с доказателства.

Подходът на Clarysec започва от прост принцип: ако клаузата за доставчика не може да бъде наблюдавана, доказана и тествана, тя не е контрол.

Zenith Blueprint: 30-стъпкова пътна карта за одитори поставя взаимоотношенията с доставчици във фазата „Контроли в действие“, стъпка 23, където споразуменията, мониторингът, въвеждането, повторната оценка и одитните доказателства се превръщат в практическа работа по ISMS. След това Zenith Controls: ръководство за съответствие между рамки съпоставя контролите за доставчици по ISO/IEC 27002:2022 към NIS2, DORA, GDPR, NIST, COBIT 2019, поддържащи ISO стандарти и одитни методологии.

Резултатът е модел за управление на доставчици, който отделът по снабдяване, правният отдел, екипът по сигурност, екипът по защита на личните данни и ръководният орган могат да използват съвместно.

Защо NIS2 превръща договорите с доставчици в доказателствени записи

NIS2 Article 20 изисква ръководните органи на съществени и важни субекти да одобряват мерките за управление на киберриска, да наблюдават тяхното прилагане и да носят отговорност за нарушения. Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурно придобиване и поддръжка, оценка на ефективността, киберхигиена, криптография, сигурност на човешките ресурси, контрол на достъпа, управление на активите и MFA, когато е приложимо.

Article 21(3) изрично въвежда надлежна проверка на доставчици. Организациите трябва да вземат предвид уязвимости, специфични за преките доставчици и доставчиците на услуги, общото качество на продуктите и практиките за киберсигурност, както и процедурите за сигурна разработка.

Тази формулировка създава практическо задължение: взаимоотношенията с доставчици трябва да бъдат основани на риска, договорно приложими и подлежащи на преглед. Въпросник към доставчик, съхранен в папка, не е достатъчен. Общ договор без срок за уведомяване при инцидент, без права за достъп до доказателства и без видимост върху подизпълнителите не е достатъчен. Сертификат на доставчик, който никой не е прегледал, не е достатъчен.

ISO/IEC 27001:2022 предоставя оперативния модел. Клаузи 4.1 до 4.4 изискват организацията да разбира контекста, заинтересованите страни, правните и договорните задължения, обхвата на ISMS и зависимостите. Клаузи 5.1 до 5.3 изискват лидерство, политика, роли и докладване. Клаузи 6.1.1 до 6.1.3 изискват оценка на риска, третиране на риска и Декларация за приложимост. Клаузи 8.1 до 8.3 изискват оперативен контрол, повторни оценки на риска и документирани резултати.

За управлението на доставчици най-важните контроли от ISO/IEC 27002:2022 Annex A включват:

• A.5.19 Информационна сигурност във взаимоотношенията с доставчици
• A.5.20 Адресиране на информационната сигурност в споразуменията с доставчици
• A.5.21 Управление на информационната сигурност във веригата на доставки на ИКТ
• A.5.22 Мониторинг, преглед и управление на промените в услугите на доставчици
• A.5.24 Планиране и подготовка за управление на инциденти
• A.5.25 Оценка и вземане на решение относно събития по информационната сигурност
• A.5.26 Реагиране при инциденти по информационната сигурност
• A.5.27 Извличане на поуки от инциденти по информационната сигурност
• A.5.28 Събиране на доказателства
• A.5.29 Информационна сигурност при прекъсване
• A.5.30 ИКТ готовност за непрекъсваемост на дейността
• A.5.31 Правни, законови, регулаторни и договорни изисквания
• A.5.34 Поверителност и защита на PII
• A.8.8 Управление на технически уязвимости
• A.8.13 Архивиране на информация
• A.8.15 Регистриране
• A.8.16 Дейности по мониторинг
• A.8.24 Използване на криптография
• A.8.32 Управление на промените

Ключът е собствеността. Една клауза има малка стойност, ако няма собственик на риска, лице, което преглежда доказателствата, лице, което проследява изключенията, и лице, което ескалира несъответствието.

Корпоративната Политика за сигурност на трети страни и доставчици прави това изрично:

„Права на одит, проверка и искане на доказателства за сигурност“

От раздел „Изисквания за управление“, клауза на политиката 5.3.4.

За МСП Политика за сигурност на трети страни и доставчици — МСП задава същото практическо очакване:

„Права на одит или наличност на доказателства за съответствие“

От раздел „Изисквания за управление“, клауза на политиката 5.3.4.

Това разграничение е важно. По-малка организация може да няма възможност да одитира на място всеки голям доставчик на облачни услуги, но може да изисква достъп до доказателства за увереност, като обхват на сертификацията по ISO/IEC 27001:2022, SOC доклади, резюмета от тестове за проникване, удостоверения за отстраняване на уязвимости, обобщения на инциденти, доклади от тестове за непрекъсваемост на дейността и потвърждения за изтриване на данни.

Трите ключови контрола за увереност относно доставчици по NIS2

В модела на Clarysec за съответствие между рамки три контрола по ISO/IEC 27002:2022 формират основата на управлението на доставчици по NIS2: 5.19, 5.20 и 5.22.

A.5.19 идентифицира риска, свързан с доставчика

Контрол A.5.19, Информационна сигурност във взаимоотношенията с доставчици, е основата. Той изисква организациите да защитават информацията и активите, до които доставчиците имат достъп или които обработват, съхраняват или управляват.

Zenith Controls категоризира това като превантивен контрол, обхващащ поверителност, цялостност и наличност, с концепцията за киберсигурност „Идентифициране“ и оперативната способност „Сигурност на взаимоотношенията с доставчици“. Той свързва A.5.19 с A.5.20, A.5.21, A.5.14, A.5.36 и A.5.10. На практика организацията идентифицира риска, свързан с доставчици, дефинира очакванията за сигурност, контролира експозицията във веригата на доставки на ИКТ, защитава предаването на информация, наблюдава съответствието и разширява задълженията за допустима употреба към външни страни.

За NIS2 това се съпоставя пряко с Article 21(2)(d) относно сигурността на веригата на доставки и Article 21(3) относно надлежната проверка на доставчици. За GDPR то подпомага изискването да се използват обработващи лични данни, които предоставят достатъчни гаранции. За DORA то подпомага управлението на ИКТ риск от трети страни, надлежната проверка преди сключване на договор, прегледа на критичността, риска от концентрация и надзора върху жизнения цикъл.

A.5.20 прави изискването приложимо

Контрол A.5.20, Адресиране на информационната сигурност в споразуменията с доставчици, превръща очакванията за сигурност в договорни задължения. Zenith Controls обяснява ясно връзката между A.5.19 и A.5.20:

„5.20 служи като договорна формализация на нуждите и рисковете за сигурността, идентифицирани по 5.19. Докато 5.19 включва оценяване на рисковете от трети страни и дефиниране на очакванията за сигурност, 5.20 гарантира, че тези очаквания са правно обвързващи чрез договори или споразумения за ниво на обслужване (SLA). Без 5.20 мерките за сигурност, идентифицирани по 5.19, не биха били приложими.“

Тук решенията за риска по NIS2 се превръщат в клаузи: уведомяване при нарушение, права на одит и достъп до доказателства, шифроване, контрол на достъпа, управление на уязвимостите, одобрение на подизпълнители, сигурно предаване, непрекъсваемост, регулаторно сътрудничество, съдействие при прекратяване и изтриване на данни.

A.5.22 доказва, че договорът е жив

Контрол A.5.22, Мониторинг, преглед и управление на промените в услугите на доставчици, не позволява увереността относно доставчици да се превърне в еднократно упражнение при въвеждане. Zenith Controls свързва A.5.22 с A.5.19 и A.5.20, но също и с A.5.29 информационна сигурност при прекъсване, A.8.8 управление на технически уязвимости, A.5.36 съответствие с политики, правила и стандарти за информационна сигурност, A.5.15 контрол на достъпа и A.8.27 сигурна системна архитектура и инженерни принципи.

Това е важно, защото услугите на доставчиците се променят. Местонахожденията на данните се променят. Подизпълнителите по обработване се променят. Появяват се уязвимости. Сертификациите изтичат. Появяват се модели на инциденти. Доставчик, който е бил приемлив миналата година, може днес да е твърде рисков.

Какво трябва да включват клаузите в договорите с доставчици по NIS2

Zenith Blueprint, фаза „Контроли в действие“, стъпка 23, дава практически набор от области за споразумения с доставчици:

„Ключовите области, които обичайно се адресират в споразуменията с доставчици, включват:

✓ Задължения за поверителност, включително обхват, срок и ограничения за разкриване пред трети страни; ✓ Отговорности за контрол на достъпа, например кой може да има достъп до вашите данни, как се управляват удостоверителните данни и какъв мониторинг е въведен; ✓ Технически и организационни мерки за защита на данните, шифроване, сигурно предаване, архивиране и ангажименти за наличност; ✓ Срокове и протоколи за докладване на инциденти, често с дефинирани срокове (например „уведомяване в рамките на 24 часа“); ✓ Право на одит, включително честота, обхват и достъп до относими доказателства (например доклади от тестове за проникване, SoA, сертификации); ✓ Контроли за подизпълнители, изискващи доставчикът да прехвърля еквивалентни задължения за сигурност към своите партньори надолу по веригата; ✓ Разпоредби при край на договора, като връщане или унищожаване на данни, възстановяване на активи и деактивиране на акаунти.“

От фазата „Контроли в действие“, стъпка 23: Организационни контроли.

Силната клауза за доставчик по NIS2 е достатъчно конкретна, за да бъде тествана. „Доставчикът трябва да поддържа подходяща сигурност“ е слаба формулировка. „Доставчикът трябва да уведоми контакта за сигурност на клиента в рамките на 24 часа за потвърдени или подозирани инциденти, засягащи клиентски системи, клиентски данни, наличност на услугата или регулаторни задължения за докладване“ е одитируема формулировка.

Клаузите за инциденти трябва да съответстват на сроковете за докладване по NIS2

NIS2 Article 23 създава поетапен модел за докладване на значителни инциденти: ранно предупреждение в рамките на 24 часа от узнаването, уведомяване за инцидент в рамките на 72 часа, междинни доклади при поискване и окончателен доклад в рамките на един месец от уведомяването за инцидента. Значителен инцидент е инцидент, който е причинил или може да причини тежко оперативно прекъсване, финансова загуба или значителни материални или нематериални вреди за други лица.

Договорите с доставчици трябва да поддържат тази времева рамка. Ако критичен доставчик на управлявани услуги се нуждае от четири дни, за да потвърди дали клиентските среди са били засегнати, клиентът може да пропусне собствения си регулаторен срок.

Корпоративната Политика за сигурност на трети страни и доставчици изисква:

„Срокове за уведомяване при нарушение (например в рамките на 24 или 72 часа, в зависимост от критичността и регулаторните изисквания)“

От раздел „Изисквания за управление“, клауза на политиката 5.3.3.

Политика за сигурност на трети страни и доставчици — МСП също изисква дефинирани срокове за уведомяване при нарушение от раздел „Изисквания за управление“, клауза на политиката 5.3.3.

За инциденти с PII корпоративната Политика за управление на инциденти и нарушения, свързани с PII свързва докладването в областта на киберсигурността, финансовия сектор, клиентите и получателите на услуги:

„[Условно] Ръководителят по защита на личните данни / PIMS Manager ТРЯБВА да координира всяко изискуемо секторно, киберсигурностно, финансово-секторно, клиентско или насочено към получател на услуга докладване на инцидент, когато инцидент с лични данни с високо въздействие изпълнява приложим праг за докладване, и ТРЯБВА да запише доказателствата за органа, получателя, срока, подаването и потвърждението в REG01 и REG10.“

От раздел „Уведомяване и комуникации“, клауза на политиката 4.4.6.

Това е зряло доказателство по NIS2: не просто имейл за уведомяване, а запис за органа, получателя, срока, подаването, потвърждението, въздействието, първопричината и последващите действия.

Съгласуване със защитата на личните данни и DORA без дублиране на програми за доставчици

Много доставчици по NIS2 също обработват лични данни. GDPR Article 28 изисква администраторите да използват обработващи лични данни, които предоставят достатъчни гаранции, и да дефинират задълженията на обработващия лични данни в писмен договор. GDPR Article 5 изисква отчетност за сигурно и законосъобразно обработване. Задълженията по GDPR при нарушения също изискват бързо сътрудничество, когато инциденти при доставчик засягат лични данни.

Корпоративната Политика за управление на обработващи лични данни, други обработващи лични данни и трети страни във връзка със защитата на личните данни задава контролната точка за одобрение:

„[И за двете роли] Собственикът на доставчика / снабдяването ТРЯБВА да гарантира, че договорите с обработващи лични данни и други обработващи лични данни включват съдействие във връзка със защитата на личните данни, увереност относно сигурността, интерфейс за инциденти чрез PII15, връщане или изтриване чрез PII10, връзка с предаванията чрез PII13 и сътрудничество при одит или увереност преди одобрение.“

От раздел „Контроли за договори и документирани инструкции“, клауза на политиката 4.3.6.

Политиката също изисква преглед на доказателствата преди одобрение:

„[Всички] Ръководителят по информационна сигурност ТРЯБВА да прегледа доказателствата за увереност относно сигурността за всяко взаимоотношение с обработващ лични данни, друг обработващ лични данни или трета страна с достъп до PII или хостинг преди одобрение и ТРЯБВА да запише резултата в REG08 или REG12.“

От раздел „Надлежна проверка и оценка на риска“, клауза на политиката 4.2.2.

DORA добавя още един слой, когато доставчикът обслужва финансов субект. DORA Articles 28 до 30 изискват управление на ИКТ трети страни, регистри на договорите за ИКТ услуги, основана на риска надлежна проверка, оценка на критичността, анализ на риска от концентрация, права на одит и проверка, права за прекратяване, стратегии за изход и задължителни договорни разпоредби. Article 30 е особено релевантен, защото изисква договорно съдържание, обхващащо описания на услугите, местоположения, защита на данните, достъп и възстановяване, нива на обслужване, съдействие при инциденти, сътрудничество с органи, права на одит, подизпълнители, мерки при извънредни ситуации и подкрепа при преход.

Практическият отговор не е три отделни програми за доставчици за NIS2, GDPR и DORA. Той е един хармонизиран модел за доказателства относно доставчици, съпоставен между рамките.

NIST CSF 2.0 е полезен, защото функцията GOVERN изисква разбиране на зависимостите, правните задължения, договорните задължения, апетита за риск, политиките, отчетността и надзора. Категорията за веригата на доставки GV.SC обхваща ролите на доставчиците, критичността, договорните изисквания, надлежната проверка, мониторинга, включването при инциденти, мониторинга на жизнения цикъл и разпоредбите при край на взаимоотношението.

Работен процес на Clarysec за въвеждане на критичен доставчик

Да приемем, че въвеждате доставчик на управлявани услуги за сигурност, който ще наблюдава EDR телеметрия, ще получава предупреждения, съдържащи потребителски идентификатори, и ще подпомага триажа на инциденти за организация в обхвата на NIS2.

Стъпка 1: класифицирайте доставчика

Запишете доставчика в регистъра на доставчиците с описание на услугата, системите и данните, до които има достъп, участието на PII, поддръжката на съществени или важни услуги, привилегирования достъп, държавите на предоставяне на услугата, подизпълнителите, зависимостите от четвърти страни, оценката на критичността, собственика на риска, собственика от страна на снабдяването и преглеждащото лице по информационна сигурност.

Това прилага ISO/IEC 27001:2022 Клаузи 4.2, 4.3, 6.1.2 и 8.1 чрез свързване на изискванията на заинтересованите страни, зависимостите, собствеността върху риска и оперативния контрол.

Стъпка 2: съпоставете риска към SoA

В Zenith Blueprint, фаза „Управление на риска“, стъпка 13, Clarysec препоръчва кръстосано съпоставяне на регулациите в регистъра на риска или SoA:

„Кръстосано съпоставяне на регулации: ако определени контроли се внедряват специално за съответствие с GDPR, NIS2 или DORA, можете да отбележите това или в Регистъра на риска (като част от обосновката на въздействието на риска), или в бележките към SoA.“

От фазата „Управление на риска“, стъпка 13: Планиране на третиране на риска и Декларация за приложимост.

За MSSP включете поне A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 до A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 и A.8.24.

Стъпка 3: изискайте приложими клаузи

Използвайте приложение за сигурност към договора с доставчика, което изисква първоначално уведомяване при инцидент в рамките на 24 часа, подробна актуализация в рамките на 72 часа, окончателно докладване на инцидента, MFA за привилегирован достъп, поименни потребителски акаунти, контроли за подизпълнители, сигурно предаване, шифроване, доказателства за увереност, регулаторно сътрудничество, доказателства за BCP и DR, съдействие при прекратяване, връщане или изтриване на данни и отнемане на достъп.

Корпоративната Политика за управление на риска от зависимост от доставчици предоставя изискването за непрекъсваемост:

„Когато е приложимо, изискване доставчикът да поддържа свои собствени планове за непрекъсваемост на дейността (BCP/DRP) и планове за управление на инциденти, да ги тества и при поискване да ни предоставя резюмета или доклади от тестове.“

От раздел „Изисквания за внедряване“, клауза на политиката 6.8.4.

Стъпка 4: изградете пакет с доказателства за увереност

Преди одобрение изискайте подписаното споразумение, SLA, приложението за сигурност, обхвата на сертификацията по ISO/IEC 27001:2022 или еквивалентна увереност, SOC доклад, когато е наличен, резюме за ръководството от тест за проникване, резюме за управление на уязвимостите, резюме на процедурата за реагиране при инциденти, резюме от BCP или DR тест, удостоверение за контрол на достъпа и MFA, списък на подизпълнителите, процедура за изтриване на данни и изход, както и DPA, когато се обработват PII.

Политика за сигурност на трети страни и доставчици — МСП прави базовите договорни доказателства измерими:

„Подписани споразумения и SLA“

От раздел „Прилагане и съответствие“, клауза на политиката 8.3.2.1.

Тя също идентифицира периодични доказателства от доставчици:

„Валидни сертификации по сигурност или актуализирани доказателства за контрол“

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.3.1.2.

За по-широка надлежна проверка на доставчици Политика за одит и мониторинг на съответствието посочва:

„Надлежната проверка на доставчици трябва да включва преглед на сертификации (например ISO 27001, SOC 2), въпросници по сигурност и записи за инциденти.“

Стъпка 5: извършвайте мониторинг въз основа на критичността

Корпоративната Политика за управление на обработващи лични данни, други обработващи лични данни и трети страни във връзка със защитата на личните данни изисква тримесечен мониторинг за високорискови взаимоотношения с PII:

„[Всички] Собственикът на доставчика / снабдяването ТРЯБВА да наблюдава активните високорискови взаимоотношения с обработващи лични данни и други обработващи лични данни на тримесечна база, а останалите активни взаимоотношения с обработващи лични данни и други обработващи лични данни на PII — ежегодно, спрямо условията от надлежната проверка, статуса на договора, статуса на увереността, отворените проблеми и датите за преглед в REG08.“

От раздел „Текущ мониторинг, съдействие, интерфейс за разкриване и изход“, клауза на политиката 4.5.1.

Така A.5.22 става реален контрол. Прегледът трябва да определи дали доставчикът остава в рамките на апетита за риск, дали доказателствата са актуални, дали има отворени проблеми, дали са възникнали инциденти и дали промените в услугата изискват повторна оценка.

Как одиторите ще тестват клаузите за доставчици по NIS2

Одиторите рядко започват с изолирано четене на вашата политика. Те избират извадка от доставчици и проследяват доказателствената следа.

Одитор по ISO/IEC 27001:2022 ще поиска инвентар на доставчиците, класификация на риска, критерии за доставчици, записи от надлежна проверка, договори, доказателства, съпоставяне към SoA и история на мониторинга. За Annex A 5.20 одиторът ще провери дали договорите от извадката съдържат приложими клаузи. За Annex A 5.22 одиторът ще тества дали докладите са прегледани, изключенията са регистрирани и действията са проследени до изпълнение.

Компетентен орган по NIS2 може да се фокусира върху това дали практиките за киберсигурност на доставчиците и процедурите за сигурна разработка са оценени съгласно Article 21(3). Преглеждащ орган, ориентиран към DORA, може да поиска записи в регистъра на ИКТ договорите, стратегии за изход, анализ на риска от концентрация и задължителни разпоредби по Article 30. Одитор по защита на личните данни може да тества договори с обработващи лични данни, прехвърляне на задължения към други обработващи лични данни, интерфейси при нарушения и доказателства за достатъчни гаранции.

Корпоративната Политика за сигурност и контрол на достъпа до PII показва как контролът на достъпа, уязвимостите, конфигурацията, мониторингът и криптографията се свързват обратно с ISO/IEC 27001:2022:

„ISO/IEC 27001:2022 — Клауза 6.1.3; Клауза 8.1; контроли от Annex A 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Адресирани чрез клаузи [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].“

От раздел „Референтни стандарти и рамки“, клауза на политиката 13.9.

Когато доставчик има достъп до PII, привилегировани системи или данни от мониторинг, доказателствата за контрол на достъпа не са отделни от увереността относно доставчика. Те са част от същата одитна следа.

Капанът при снабдяването: подписани договори без оперативна увереност

Най-честият провал в управлението на доставчици по NIS2 не е липсата на договори. Това е пропастта между договорния текст и ежедневната операция.

Договорът може да изисква годишни резюмета от тестове за проникване, но да няма собственик, който да ги изисква. Може да изисква уведомяване при инцидент в рамките на 24 часа, но доставчикът да разполага само с общ адрес за поддръжка. Може да изисква одобрение на подизпълнители, но отделът по снабдяване никога да не получава уведомления за промяна. Може да включва права на одит, но организацията да няма процес за оценяване на изключенията в SOC доклади. Може да изисква изтриване на данни при прекратяване, но ИТ никога да не валидира деактивирането на акаунти.

Zenith Blueprint, фаза „Контроли в действие“, стъпка 23, обяснява как контролите за доставчици оживяват:

„На практика този контрол се реализира чрез:

✓ Оценки на риска за доставчици, ✓ Въпросници за надлежна проверка преди ангажиране, ✓ Договорни шаблони с вградени условия за сигурност, ✓ Контролни списъци за въвеждане на доставчици, които включват предоставяне на достъп и настройка на мониторинг, ✓ Текущи повторни оценки, особено когато обхватът на доставчика се променя, възникват инциденти или предстоят подновявания.

И този контрол не спира при доставчиците от първо ниво. Вашият доставчик може да възложи дейности на свои собствени доставчици и вие все още може да носите риска.“

Това е посланието по NIS2 към ръководния орган: възлагането на предоставянето на услуга не възлага отчетността на външен изпълнител.

Контролен списък за привеждане на договорите с доставчици по NIS2 в съответствие

Започнете с първите 20 доставчици по критичност и проведете фокусирано упражнение за отстраняване:

• Идентифицирайте доставчиците, които поддържат съществени или важни услуги.
• Потвърдете дали всеки доставчик обработва PII, поддържа регулирани услуги или има привилегирован достъп.
• Определете бизнес собственик, собственик от страна на снабдяването и преглеждащо лице по сигурността.
• Проверете дали оценката на риска за доставчика е актуална и съгласувана с действителния обхват на услугата.
• Потвърдете, че договорът включва базови изисквания за сигурност, уведомяване при инцидент, права на одит или достъп до доказателства, контроли за подизпълнители, непрекъсваемост, сигурно предаване, контрол на достъпа, сътрудничество при уязвимости и клаузи за изход.
• Потвърдете, че сроковете при нарушения поддържат нуждите от ескалация в рамките на 24 часа и 72 часа, когато е релевантно.
• Изискайте актуализирани доказателства за увереност, включително сертификации, SOC доклади, резюмета от тестове за проникване, BCP или DR тестове и история на инциденти.
• Преглеждайте доказателствата, а не просто ги съхранявайте.
• Регистрирайте изключенията и определете собственици на отстраняването.
• Актуализирайте SoA и регистъра на риска, когато контролите за доставчици поддържат NIS2, GDPR, DORA или клиентски ангажименти.
• Планирайте честотата на мониторинг въз основа на критичността на доставчика.
• Тествайте един път за ескалация при инцидент с доставчик.
• Тествайте един път за прекратяване на доставчик, включително връщане на данни, изтриване, възстановяване на активи и отнемане на достъп.

Ако не можете да докажете тези точки за критичен доставчик, договорът все още не е готов за одит.

Превърнете клаузите за доставчици в доказателства за надзор

Управлението на доставчици по NIS2 вече е активна оперативна дисциплина. Надзорните органи, клиентите, сертификационните одитори, екипите по защита на личните данни, партньорите от финансовия сектор и ръководните органи няма да питат само дали съществуват клаузи за доставчици. Те ще питат дали клаузите са основани на риска, приложими, наблюдавани, подкрепени с доказателства и свързани с докладване на инциденти, непрекъсваемост, контрол на достъпа, управление на уязвимостите, прехвърляне на задължения към подизпълнители и прекратяване.

Clarysec помага на организациите да затворят тази празнина чрез Zenith Blueprint за превръщане на контролите за доставчици във фази на ISMS, третиране на риска, записи в SoA, процедури за въвеждане и одитни доказателства. Zenith Controls съпоставя контролите за доставчици по ISO/IEC 27002:2022 A.5.19, A.5.20 и A.5.22 към NIS2, DORA, GDPR, NIST, COBIT 2019, поддържащи ISO стандарти и одитни методологии. Политиките на Clarysec за доставчици и защита на личните данни предоставят структурата на клаузите, очакванията за доказателства и процедурите за мониторинг, които правят увереността относно доставчици защитима.

Следващото действие е просто: изберете пет критични доставчици, направете извадка от договорите им, съпоставете всяка клауза към третиране на риска по ISO/IEC 27001:2022 и контролите от Annex A, изискайте актуални доказателства за увереност и проведете настолно упражнение за 24-часово уведомяване при инцидент. Ако доказателствената следа се прекъсне, инструментариумите на Clarysec ви дават структурата да я поправите преди инцидент, клиентски преглед или надзорно искане да го направи вместо вас.