Съпоставяне на доказателства по NIS2 с ISO 27001:2022 за 2026 г.

Проблемът с NIS2 през 2026 г. не е осведомеността, а доказването

Понеделник сутрин е, 08:35. Мария, наскоро назначеният CISO на бързо растящ доставчик на B2B облачни и управлявани услуги, се включва в тримесечната среща на управителния съвет по риска с обемен анализ на пропуските по NIS2, отворен на лаптопа ѝ. Първият слайд изглежда успокояващо. Политики има. Оценка на риска има. Реагирането при инциденти е документирано. Доставчиците са изброени. Сканиранията за уязвимости се изпълняват всеки месец.

Тогава председателят задава въпроса, който променя срещата:

„Можем ли да докажем, че тези мерки са функционирали през последното тримесечие, и можем ли да покажем кои контроли, собственици и записи по ISO 27001:2022 подкрепят всяко задължение по NIS2?“

В залата настъпва тишина.

Правният отдел знае, че дружеството попада в обхвата на NIS2, защото предоставя управлявани ИКТ и облачни услуги на клиенти в ЕС. Функцията по съответствие знае, че Article 21 изисква технически, оперативни и организационни мерки за управление на риска за киберсигурността. Оперативните екипи знаят, че прилагат корекции, преглеждат доставчици и наблюдават логове. Но доказателствата са разпръснати в системи за управление на заявки, експорти от SIEM, папки с политики, електронни таблици, облачни конзоли, портали на доставчици и протоколи от срещи.

Никой не може бързо да покаже защитима верига от NIS2 Article 21 до обхват, риск, контрол, политика, собственик, процедура, оперативен запис и одитна констатация по ISO 27001:2022.

Това е реалното предизвикателство за 2026 г.

Много организации вече не питат: „Попадаме ли в обхвата на NIS2?“ Те задават по-трудния въпрос: „Можем ли да докажем, че техническите ни мерки по NIS2 действително работят?“ Отговорът не може да бъде еднократна таблица за съпоставяне. Той трябва да бъде действащ оперативен модел в рамките на системата за управление на сигурността на информацията (ISMS), където правните задължения се превеждат в рискове, политики, контроли, собственици, доказателства и непрекъснато подобрение.

Моделът на Clarysec използва ISO/IEC 27001:2022 като гръбнак на системата за управление, NIS2 Article 21 като набор от регулаторни задължения, клаузите на политиките като оперативен правилник, Zenith Blueprint: 30-стъпкова пътна карта за одитора като път за внедряване и Zenith Controls: Ръководство за кръстосано съответствие като карта за кръстосано съответствие за ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF и COBIT-ориентирано уверение.

Започнете с обхвата, защото доказателствата по NIS2 започват преди контролите

Често срещан провал при NIS2 е директното преминаване към MFA, регистриране, реагиране при инциденти и управление на уязвимостите, преди да са потвърдени обхватът на субекта, обхватът на услугите и юрисдикционният обхват.

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

За доставчици на облачни услуги, SaaS платформи, MSP, MSSP и доставчици на цифрова инфраструктура тази работа по определяне на обхвата не е теоретична. Article 3 изисква държавите членки да разграничават съществени и важни субекти. Article 27 изисква ENISA да поддържа регистър за няколко категории цифрови и ИКТ доставчици, включително доставчици на DNS услуги, регистри на TLD имена, доставчици на услуги за регистрация на домейн имена, доставчици на облачни услуги, доставчици на услуги за центрове за данни, доставчици на мрежи за доставка на съдържание, доставчици на управлявани услуги, доставчици на управлявани услуги по сигурност, онлайн пазари, онлайн търсачки и платформи за социални мрежи.

ISO 27001:2022 предоставя правилната структура. Клаузи 4.1 до 4.4 изискват организацията да разбира външните и вътрешните фактори, заинтересованите страни, изискванията, интерфейсите и зависимостите, след което да дефинира обхвата на ISMS. NIS2 трябва да бъде отразена тук, а не да остане в правен меморандум.

Практичен запис за обхвата по NIS2 трябва да включва:

• Анализ на юридическото лице и установяването в ЕС
• Сектор и категория услуга по NIS2
• Статус на съществен или важен субект, когато е потвърден с национален закон или с определяне от компетентен орган
• Релевантност към регистъра на ENISA, когато е приложимо
• Критични услуги, предоставяни на клиенти
• Мрежови и информационни системи, които поддържат тези услуги
• Зависимости от облачни услуги, центрове за данни, телекомуникации, мониторинг на сигурността, идентичност и доставчици на софтуер
• Връзки към DORA, GDPR, клиентски договори и секторно специфични задължения
• Хранилища за доказателства, собственици на системи и периодичност на прегледа

Тук трябва правилно да се разграничи и DORA. NIS2 признава, че когато секторно специфичен правен акт на ЕС налага еквивалентни задължения за управление на риска за киберсигурността или уведомяване за инциденти, този секторен режим се прилага вместо съответните разпоредби на NIS2. За обхванатите финансови субекти DORA обикновено е приложимият режим за киберсигурност и докладване на ИКТ инциденти. DORA се прилага от 17 януари 2025 г. и обхваща управление на ИКТ риска, докладване на инциденти, тестване на цифровата оперативна устойчивост, риск от ИКТ трети страни и надзор върху критични доставчици на ИКТ услуги от трети страни.

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

ISO 27001:2022 като операционна система за съответствие с NIS2

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

ISO 27001:2022 е особено подходящ за въвеждане на това изискване в оперативна практика, защото налага три дисциплини.

Първо, управление. Клаузи 5.1 до 5.3 изискват ангажимент на висшето ръководство, съгласуване със стратегическата посока, осигуряване на ресурси, комуникация, възлагане на отговорности и документирана политика за сигурност на информацията. Това пряко съответства на NIS2 Article 20, който изисква управленските органи да одобряват мерките за управление на риска за киберсигурността, да надзирават внедряването и да получават обучение.

Второ, третиране на риска. Клаузи 6.1.1 до 6.1.3 изискват повторяем процес за оценка на риска, собственици на риска, оценяване на риска, варианти за третиране, избор на контроли, Декларация за приложимост, План за третиране на риска и одобряване на остатъчния риск.

Трето, оперативен контрол. Клауза 8.1 изисква организацията да планира, внедрява и контролира процесите на ISMS, да поддържа документирана информация, да контролира промените и да управлява външно предоставени процеси, продукти и услуги, релевантни за ISMS.

Това превръща NIS2 от правен контролен списък в оперативен модел на контролите.

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

Политиката е мястото, където NIS2 става оперативно поведение

Политиките често се третират като шаблони. За NIS2 това е опасно. Регулатор или одитор няма да бъде убеден от папка с политики, ако политиките не възлагат отговорност, не дефинират записи, не се свързват с рискове и не генерират доказателства.

Корпоративната Политика за правно и регулаторно съответствие поставя основата в клауза 6.2.1:

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

Тази клауза е мостът между NIS2 и ISO 27001:2022. NIS2 Article 21 не се посочва просто като външно изискване. Той се декомпозира в задължения по политики, съпоставя се с контроли, възлага се на собственици и се тества чрез доказателства.

За по-малки организации Политиката за правно и регулаторно съответствие за МСП запазва същата концепция в олекотен вид. Клауза 5.1.1 изисква:

Управителят трябва да поддържа прост, структуриран Регистър на съответствието, който изброява:

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

След това третирането на риска превръща задължението в действие. Корпоративната Политика за управление на риска, клауза 6.4.2 гласи:

Длъжностното лице по управление на риска трябва да гарантира, че третирането е реалистично, ограничено във времето и съпоставено с контролите от Приложение A на ISO/IEC 27001.

За МСП Политиката за управление на риска за МСП, клауза 5.1.2, дава минимално необходимия запис за риск:

Всеки запис за риск трябва да включва: описание, вероятност, въздействие, оценка, собственик и план за третиране.

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

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

Всички внедрени контроли трябва да бъдат одитируеми, подкрепени с документирани процедури и със съхранени доказателства за функционирането им.

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

Пътят на Clarysec от съпоставяне към функциониране

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

В етапа „Управление на риска“ Step 13 указва на екипите да добавят проследимост между рискове, контроли и клаузи:

✓ Съпоставете контролите с рисковете: В плана за третиране във вашия Регистър на риска сте изброили определени контроли за всеки риск. Можете да добавите колона „Референция към контрол от Приложение A“ към всеки риск и да посочите номерата на контролите.

За NIS2 това означава, че регистърът на риска и Декларацията за приложимост трябва да показват защо контроли като 8.8 Управление на техническите уязвимости, 5.19 Сигурност на информацията във взаимоотношенията с доставчици и 5.24 Планиране и подготовка за управление на инциденти са приложими.

Step 14 от Zenith Blueprint прави регулаторното съпоставяне изрично:

За всяка регулация, ако е приложима, можете да създадете проста таблица за съпоставяне (например приложение към доклад), която изброява ключовите изисквания за сигурност на регулацията и съответните контроли/политики във вашата ISMS.

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

Step 19 преминава от проект към функциониране:

Свържете всеки от тези документи със съответния контрол във вашата Декларация за приложимост или ръководство на ISMS. Те ще служат като доказателство за внедряване и като вътрешна референция.

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

Step 26 обяснява как трябва да се събират доказателства за одит:

Докато събирате доказателства, записвайте констатациите си. Отбелязвайте къде нещата съответстват на изискването (положителни констатации) и къде не съответстват (потенциални несъответствия или наблюдения).

За NIS2 това означава извадково тестване на доказателства, преди регулатор, клиентски оценител или сертификационен одитор да ги поиска.

Ролята на Zenith Controls за кръстосаното съответствие

Zenith Controls не е отделна рамка за контрол. Това е ръководството на Clarysec за кръстосано съответствие при съпоставяне на контроли по ISO/IEC 27001:2022 и ISO/IEC 27002:2022 със свързани контроли, одиторски очаквания и външни рамки. То помага на екипите да разберат как един контрол по ISO 27001:2022 може да подкрепя NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT-ориентирано уверение.

Три контрола по ISO 27001:2022 са особено важни за съпоставяне на доказателства по NIS2.

Контрол 5.1 Политики за сигурност на информацията е входната точка, защото NIS2 Article 21 включва анализ на риска и политики за сигурност на информационните системи. Ако техническа мярка по NIS2 не е отразена в политика, тя е трудна за управление и трудна за последователен одит.

Контрол 5.36 Съответствие с политики, правила и стандарти за сигурност на информацията е проверката на реалността. Той свързва изискванията на политиките с действителното съответствие с вътрешни правила, стандарти и външни задължения. В контекста на NIS2 това е мястото, където организацията пита дали прави това, което картата ѝ по Article 21 твърди, че прави.

Контрол 8.8 Управление на техническите уязвимости е една от най-трудните области за тестване през 2026 г. Управлението на уязвимостите е пряко релевантно за сигурно придобиване, разработка, поддръжка, обработване и оповестяване на уязвимости. То подкрепя също тестването и отстраняването по DORA, отчетността за сигурността по GDPR, резултатите Identify и Protect по NIST CSF и извадковото тестване при одит по ISO 27001.

Поддържащите стандарти могат да подобрят дизайна, без да изискват допълнителни сертификации. ISO/IEC 27002:2022 предоставя указания за внедряване на контролите от Приложение A. ISO/IEC 27005 подпомага управлението на риска за сигурността на информацията. ISO/IEC 27017 подпомага сигурността на облачните услуги. ISO/IEC 27018 подпомага защитата на лична идентифицираща информация (PII) в сценарии с обработващ в публичен облак. ISO 22301 подпомага непрекъсваемостта на дейността. ISO/IEC 27035 подпомага управлението на инциденти. ISO/IEC 27036 подпомага сигурността във взаимоотношенията с доставчици.

Целта не са повече стандарти сами по себе си. Целта е по-добър дизайн на доказателствата.

Практически пример: изграждане на пакет с доказателства за уязвимости по NIS2

Да разгледаме SaaS платформата на Мария. Тя обслужва производствени клиенти в ЕС и зависи от облачни услуги, компоненти с отворен код, CI/CD процеси и управляван мониторинг. В доклада за пропуски пише „управление на уязвимостите внедрено“, но доказателствата са разпръснати в скенери, Jira, GitHub, инструменти за облачна конфигурация и заявки за промяна.

Пакет с доказателства, готов за NIS2, може да бъде изграден в един фокусиран спринт.

Step 1: Дефинирайте рисковия сценарий

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

Регистърът на риска трябва да включва описание, вероятност, въздействие, оценка, собственик и план за третиране. Планът за третиране трябва да препраща към контрол 8.8 Управление на техническите уязвимости по ISO 27001:2022, както и към свързани контроли за инвентар на активите, сигурна разработка, регистриране, контрол на достъпа, управление на доставчици и реагиране при инциденти.

Step 2: Съпоставете риска с NIS2 Article 21

Рискът подкрепя изискванията на Article 21 за сигурно придобиване, разработка и поддръжка, обработване и оповестяване на уязвимости, анализ на риска, обработване на инциденти, сигурност на веригата на доставки и оценка на ефективността на контролите.

Step 3: Закрепете оперативните правила в политика

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

Корпоративната Политика за тестване на сигурността и упражнения тип red team, клауза 6.1 гласи:

Видове тестове: Програмата за тестване на сигурността трябва да включва най-малко: (a) сканиране за уязвимости, състоящо се от автоматизирани седмични или месечни сканирания на мрежи и приложения за идентифициране на известни уязвимости; (b) тестове за проникване, състоящи се от ръчно, задълбочено тестване на конкретни системи или приложения от квалифицирани тестери за идентифициране на сложни слабости; и (c) упражнения тип red team, състоящи се от сценарийно базирани симулации на реални атаки, включително социално инженерство и други тактики, за тестване на способностите на организацията за откриване и реагиране като цяло.

Тази клауза създава защитима базова линия за тестване. Тя също така съответства на очакването на DORA за повтарящо се, риск-базирано тестване на цифровата оперативна устойчивост за обхванатите финансови субекти.

Step 4: Дефинирайте метаданните за доказателствата

Политиката за одит и мониторинг на съответствието за МСП, клауза 6.2.3 гласи:

Метаданните (например кой ги е събрал, кога и от коя система) трябва да бъдат документирани.

За доказателства за уязвимости пакетът трябва да обхваща:

• Име и конфигурация на скенера
• Дата и час на сканиране
• Обхват на активите и изключения
• Критични и високи констатации
• Номер на заявка и собственик
• Решение за корекция или смекчаване
• Решение за приемане на риска, когато е приложимо
• Дата на отстраняване
• Валидиращо сканиране
• Връзка към запис за промяна
• Собственик на изключението и дата на изтичане

Step 5: Добавете доказателства от регистриране

Политиката за регистриране и мониторинг за МСП, клауза 5.4.4 включва системни логове като:

Системни логове: промени в конфигурацията, административни действия, инсталации на софтуер, дейности по прилагане на корекции

Само заявка за корекция може да не докаже, че промяната е извършена. Логове за конфигурация, административни действия и записи за инсталиране на софтуер укрепват веригата от доказателства.

Step 6: Проведете примерен одит

Изберете пет критични или високи уязвимости от предходното тримесечие. За всяка позиция проверете дали активът е бил в инвентара, скенерът е открил констатацията, заявка е била отворена в рамките на SLA, собственик е бил назначен, отстраняването е съответствало на степента на сериозност и експлоатируемостта, логовете показват промяната, валидацията потвърждава приключването и всяко изключение има одобрение от собственик на риска с дата на изтичане.

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

Сигурността на доставчиците е управление на екосистема

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

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

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

Единен регистър на доказателствата за доставчици може да подкрепя NIS2, DORA и ISO 27001:2022.

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

Един работен поток за инциденти за NIS2, DORA и GDPR

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

DORA има сходен жизнен цикъл за финансовите субекти: откриване, класификация, регистриране, оценка на тежестта, ескалация, комуникация с клиенти, докладване към органи, анализ на първопричините и отстраняване. GDPR добавя анализ на нарушение на сигурността на личните данни, включително роли на администратор и обработващ лични данни, въздействие върху субектите на данни и 72-часов срок за уведомяване, когато е приложимо.

Правилният дизайн не е три процеса за инциденти. Това е един работен поток за инциденти с регулаторни разклонения за вземане на решения.

Политиката за реагиране при инциденти за МСП, клауза 5.4.1 гласи:

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

Силен регистър на инцидентите трябва да включва:

Връзката с GDPR не трябва да се подценява. Компетентните органи по NIS2 могат да информират надзорните органи по GDPR, когато пропуски в управлението на риска за киберсигурността или в докладването могат да доведат до нарушение на сигурността на личните данни. Следователно ISMS трябва да направи оценката на поверителността част от първоначалната класификация на инцидентите, а не последваща мисъл.

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

Организация, готова за 2026 г., трябва да очаква един и същ контрол да бъде тестван през различни перспективи.

Одитор по ISO 27001:2022 ще започне от ISMS. Той ще попита дали задълженията по NIS2 са идентифицирани като изисквания на заинтересовани страни, дали обхватът на ISMS покрива релевантните услуги и зависимости, дали рисковете са оценени и третирани, дали Декларацията за приложимост обосновава приложимите контроли и дали записите доказват функционирането.

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

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

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

Оценител по NIST CSF 2.0 или COBIT 2019 стил ще се фокусира върху управление, собственост на риска, показатели за изпълнение, текущи и целеви резултати, способност на процесите и съгласуване с корпоративния апетит за риск.

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

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

Това е оперативният стандарт, към който екипите по NIS2 трябва да изграждат.

Отчетност на ръководството: управителният съвет не може да делегира NIS2 извън себе си

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

Това съответства на изискванията за лидерство в ISO 27001:2022. Висшето ръководство трябва да гарантира, че политиката и целите за сигурност на информацията са съгласувани със стратегическата посока, че изискванията на ISMS са интегрирани в бизнес процесите, че са осигурени ресурси, че значимостта се комуникира, че отговорностите са възложени и че се насърчава непрекъснато подобрение.

Управителният съвет не се нуждае от сурови експорти от скенери или пълни SIEM логове. Той се нуждае от уверение, годно за вземане на решения.

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

1. Промени в обхвата и регулаторния статус
2. Най-значими рискове по NIS2 и статус на третирането им
3. Табло за ефективност на контролите по Article 21
4. Значими инциденти, предотвратени инциденти и решения за докладване
5. Изключения за риск от доставчици и облачни услуги
6. Констатации от вътрешен одит, коригиращи действия и просрочени доказателства

Този пакет предоставя на ръководството информацията, необходима за одобряване на мерки, оспорване на изключения и приемане на остатъчния риск.

Оперативният модел на Clarysec за 2026 г.

Въвеждането на техническите мерки по NIS2 в оперативна практика с ISO 27001:2022 изисква прост, но дисциплиниран модел:

• Включете NIS2, DORA, GDPR и договорните задължения в обхвата на ISMS
• Съпоставете задълженията с рискове, политики, контроли, собственици и доказателства
• Използвайте Декларацията за приложимост като единен източник на истина за контролите
• Изградете пакети с доказателства за високорискови области по Article 21
• Интегрирайте докладването на инциденти в единен регулаторен работен поток
• Третирайте сигурността на доставчиците като жизнен цикъл, а не като въпросник
• Провеждайте вътрешни одити с реални извадки
• Докладвайте ефективността на контролите на управленските органи
• Подобрявайте въз основа на инциденти, одитни констатации, тестове и регулаторни промени

За Мария повратният момент беше осъзнаването, че не ѝ е необходим отделен проект по NIS2. Необходим ѝ е по-силен механизъм за доказателства в ISMS.

Политиките на Clarysec, Zenith Blueprint и Zenith Controls са проектирани да работят заедно. Политиките дефинират очаквано поведение и записи. Zenith Blueprint дава 30-стъпковия път за внедряване и одит. Zenith Controls предоставя съпоставянето за кръстосано съответствие, така че NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF и COBIT-ориентираното уверение да могат да се управляват като една съгласувана програма.

Следваща стъпка: изградете карта на доказателствата от NIS2 към ISO 27001:2022

Ако работата ви по NIS2 все още живее в таблица с пропуски, 2026 г. е годината да я въведете в оперативна практика.

Започнете с една високорискова техническа мярка, като управление на уязвимостите, обработване на инциденти или сигурност на доставчиците. Съпоставете я с рискове по ISO 27001:2022, политики, контроли от Приложение A, собственици, процедури и доказателства. След това направете извадка от записите за последното тримесечие и задайте трудния въпрос: би ли удовлетворило това регулатор, клиентски оценител и одитор по ISO 27001:2022?

Clarysec може да ви помогне да изградите този отговор чрез библиотеката с политики, Zenith Blueprint и Zenith Controls.

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