Доказателства за регистрация по NIS2 в ISO 27001:2022

Имейлът пристигна във входящата поща на Анна с тихо тупване, което прозвуча повече като сирена. Като CISO на CloudFlow, бързо растящ B2B SaaS доставчик, обслужващ клиенти в целия ЕС, тя беше свикнала с въпросници по сигурността, одити при възлагане на поръчки и надзорни одити по ISO 27001. Това съобщение беше различно.

Темата гласеше: „Information Request Regarding National Implementation of Directive (EU) 2022/2555 (NIS2).“ Националният орган по киберсигурност изискваше CloudFlow да потвърди своята класификация, да подготви информация за регистрация на субекта, да идентифицира услугите в обхвата и да бъде готова да докаже мерките за управление на риска за киберсигурността.

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

Можеше ли CloudFlow бързо и защитимо да докаже, че нейната Система за управление на информационната сигурност (СУИС) по ISO 27001:2022 покрива задълженията по NIS2?

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

За SaaS, облачни услуги, управлявани услуги, управлявана сигурност, центрове за данни, цифрова инфраструктура и определени доставчици от финансовия сектор реалният въпрос вече не е „Имаме ли политика за сигурност?“. Въпросът е: „Можем ли да покажем доказателствена верига от правното задължение до обхвата на СУИС, третирането на риска, функционирането на контролите и управленския надзор?“

Най-силната програма за готовност по NIS2 не е паралелна електронна таблица. Тя е проследим доказателствен модел в ISO 27001:2022.

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

NIS2 се прилага широко за публични или частни субекти в секторите, изброени в Приложение I и Приложение II, които достигат или надхвърлят съответния праг за средно предприятие. Тя обхваща и определени субекти независимо от размера, включително доставчици на обществени електронни съобщителни мрежи или услуги, доставчици на удостоверителни услуги, регистри на TLD, доставчици на DNS услуги, единствени доставчици на съществени услуги и субекти, чието прекъсване може да засегне обществената безопасност, здравето, системния риск или националната или регионалната критичност.

За технологичните дружества цифровите категории са особено важни. Приложение I включва цифрова инфраструктура, като доставчици на cloud computing услуги, доставчици на услуги на центрове за данни, доставчици на мрежи за доставка на съдържание, доставчици на удостоверителни услуги, доставчици на DNS услуги и доставчици на обществени електронни съобщителни мрежи или услуги. Приложение I включва и управление на ИКТ услуги за услуги бизнес към бизнес, включително доставчици на управлявани услуги и доставчици на управлявани услуги по сигурност. Приложение II включва цифрови доставчици, като онлайн пазари, онлайн търсачки и платформи за услуги на социални мрежи.

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

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

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

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

Започнете с обхвата на СУИС, а не с формуляра в портала

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

Клаузи 4.1 до 4.4 изискват организацията да определи вътрешните и външните фактори, да идентифицира заинтересованите страни и техните изисквания, да реши кои изисквания се адресират чрез СУИС, да дефинира обхвата на СУИС, като отчете интерфейсите и зависимостите, да документира този обхват и да управлява процесите на СУИС.

За NIS2 този обхват трябва да отговори на практически въпроси:

• Кои услуги в ЕС, правни субекти, дъщерни дружества, платформи, инфраструктурни компоненти и бизнес звена са релевантни?
• Коя категория от Приложение I или Приложение II може да се прилага?
• Организацията съществен субект ли е, важен субект ли е, обхваната ли е от DORA, извън обхват ли е или очаква национална класификация?
• Кои услуги са критични за клиентите, обществената безопасност, финансовата стабилност, здравеопазването, цифровата инфраструктура или други регулирани сектори?
• Кои доставчици на облачни услуги, MSP, MSSP, центрове за данни, подизпълнители и други доставчици поддържат тези услуги?
• Кои държави членки, компетентни органи, CSIRT, надзорни органи по защита на данните и финансови надзорни органи може да са релевантни?

Zenith Blueprint: An Auditor’s 30-Step Roadmap на Clarysec Zenith Blueprint поставя тази работа рано, в Step 2, Stakeholder Needs and ISMS Scope. Той указва на организациите да идентифицират регулатори и органи, да прегледат правните и регулаторните изисквания, да прегледат договори и споразумения, да проведат интервюта със заинтересовани страни и да отчетат очакваните индустриални стандарти.

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

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

Политиката за правно и регулаторно съответствие за МСП на Clarysec Политика за правно и регулаторно съответствие - МСП определя ясно целта:

„Тази политика определя подхода на организацията за идентифициране, изпълнение и доказване на съответствие с правни, регулаторни и договорни задължения.“

За по-големи програми Политиката за правно и регулаторно съответствие на Clarysec Политика за правно и регулаторно съответствие е още по-конкретна:

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

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

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

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

Article 21(2) изброява минимални области, включително анализ на риска и политики за сигурност на информационните системи, обработване на инциденти, непрекъсваемост на дейността, резервни копия, аварийно възстановяване, управление при кризи, сигурност на веригата на доставки, сигурно придобиване и разработка, обработване на уязвимости, оценка на ефективността, киберхигиена, обучение, криптография, сигурност на човешките ресурси, контрол на достъпа, управление на активите, многофакторна или непрекъсната автентикация и сигурни комуникации, когато е уместно.

ISO 27001:2022 естествено се съпоставя с тази структура. Клаузи 6.1.1 до 6.1.3 изискват оценка на риска и третиране на риска, включително критерии за приемане на риска, собственици на риска, анализ на вероятността и последствията, план за третиране на риска, сравнение с контролите от Приложение A и Декларация за приложимост. Клауза 8 изисква оперативно планиране и контрол, доказателства, че процесите са функционирали по план, контрол на промените, контрол върху външно предоставяни процеси, периодични оценки на риска и документирани резултати от третирането. Клауза 9.1 изисква мониторинг, измерване, анализ и оценяване. Клауза 9.2 изисква вътрешен одит. Клауза 10.2 изисква действия по несъответствия и коригиращи действия.

Политиката за управление на риска на Clarysec Политика за управление на риска - МСП превръща това в оперативно правило:

„Всички идентифицирани рискове трябва да бъдат записани в Регистъра на риска.“

Корпоративната Политика за управление на риска Политика за управление на риска свързва третирането на риска с избора на контроли по ISO 27001:2022:

„Решенията за контроли, произтичащи от процеса на третиране на риска, следва да бъдат отразени в Декларацията за приложимост (SoA).“

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

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

Включете управлението по Article 20 в доказателствата за управителния орган

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

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

Клаузи 5.1 до 5.3 на ISO 27001:2022 подкрепят този модел на управление, като изискват ангажираност на висшето ръководство, съгласуване на целите за информационна сигурност с бизнес стратегията, интегриране на изискванията на СУИС в бизнес процесите, ресурси, комуникация, отчетност и докладване на резултатността на СУИС пред висшето ръководство.

Политиката за роли и отговорности в управлението на Clarysec Политика за роли и отговорности в управлението определя ролята на връзка по сигурността като лице, което:

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

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

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

• Одобрение от управителния орган на рамката за управление на риска за киберсигурността.
• Протоколи от преглед от ръководството, обхващащи обхвата по NIS2, рискове, инциденти, доставчици и готовност.
• Записи за обучение на членовете на управителния орган и служителите.
• RACI матрица за задълженията по NIS2, контролите по ISO 27001:2022, докладването на инциденти, уверението за доставчици и регулаторната комуникация.
• Доказателства, че задълженията по NIS2 са включени във вътрешния одит и мониторинга на съответствието.
• Проследяване на коригиращи действия за пропуски, просрочени рискове, изключения и неуспешни тестове.

Articles 32 and 33 също правят качеството на доказателствата важно, като идентифицират фактори за сериозни нарушения, като повторни нарушения, неизпълнение на задължението за уведомяване или отстраняване на значими инциденти, неизпълнение на мерки за отстраняване на недостатъци след задължителни указания, възпрепятстване на одити или мониторинг и предоставяне на невярна или грубо неточна информация. Слабите доказателства могат да се превърнат в проблем при прилагането, дори когато техническите контроли съществуват.

Подгответе доказателства за контакт с органите и докладване на инциденти преди 02:00 ч.

Най-болезнените провали при докладване на инциденти често започват с базов въпрос: „Кого уведомяваме?“ По време на ransomware, DNS отказ, компрометиране на облачна услуга или експозиция на данни екипите губят време да търсят правилния CSIRT, компетентен орган, надзорен орган по защита на данните, финансов надзорен орган, канал към правоохранителни органи, клиентски шаблон и вътрешен одобряващ.

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

Zenith Blueprint, във фазата Controls in Action, Step 22, третира контакта с органите като подготовка, а не като паника:

Принципът тук е прост: ако вашата организация стане цел на кибератака, участва в нарушение на сигурността на данните или е обект на разследване, кой ще се свърже с органите? Как ще знае какво да каже? При какви условия ще бъде иницииран такъв контакт? На тези въпроси трябва да се отговори предварително, а не постфактум.

Zenith Controls: The Cross-Compliance Guide на Clarysec Zenith Controls обхваща ISO/IEC 27002:2022 контрол 5.5, Контакт с органи. Той класифицира контрола като превантивен и коригиращ, свързан с поверителност, цялостност и наличност, и с концепциите Identify, Protect, Respond и Recover. Той също свързва контрол 5.5 с ISO/IEC 27002:2022 контроли 5.24 Планиране и подготовка за управление на инциденти по информационна сигурност, 6.8 Докладване на събития по информационна сигурност, 5.7 Разузнаване за заплахи, 5.6 Контакт със специални групи по интереси и 5.26 Реагиране при инциденти по информационна сигурност.

От гледна точка на междурегулаторното съответствие Zenith Controls съпоставя контакта с органите с Article 23 от NIS2, уведомяване за нарушения по GDPR, докладване на инциденти по DORA, NIST SP 800-53 IR-6 Докладване на инциденти и практики за външна ескалация по COBIT 2019. Един регистър на контактите с органите може да обслужва множество задължения, ако е проектиран правилно.

Политиката за реагиране при инциденти на Clarysec Политика за реагиране при инциденти - МСП прави правния триаж изричен:

„Когато са засегнати клиентски данни, Управителят трябва да оцени правните задължения за уведомяване въз основа на приложимостта на GDPR, NIS2 или DORA.“

Силен доказателствен пакет за контакт с органите трябва да включва:

• Данни за контакт с компетентния орган и CSIRT по държава членка и услуга.
• Контакти на надзорните органи по защита на данните за уведомяване за нарушение на сигурността на личните данни по GDPR.
• Контакти на финансови надзорни органи, ако DORA се прилага.
• Маршрути за контакт с правоохранителни органи и звена за киберпрестъпност.
• Оторизирани вътрешни комуникатори и заместници.
• Прагове за инциденти по NIS2, GDPR, DORA, клиентски договори и киберзастраховане.
• Шаблони за 24-часово, 72-часово, междинно и едномесечно докладване.
• Записи от tabletop упражнения, които тестват външно уведомяване.
• Записи за предишни уведомления, решения за неуведомяване и правна обосновка.

Съпоставете NIS2 Article 21 с контролите на ISO 27001 и доказателствата по политики

Само сертификатът не отговаря на въпроса на регулатора. Съпоставянето на контролите отговаря. Следващата таблица дава на екипите по сигурност и съответствие практичен мост между областите на NIS2 Article 21, контролите по ISO/IEC 27002:2022, опорите в политиките на Clarysec и доказателствата.

Zenith Controls на Clarysec обхваща и ISO/IEC 27002:2022 контрол 5.31, Правни, законови, регулаторни и договорни изисквания, като превантивен контрол с въздействие върху поверителност, цялостност и наличност. Той свързва 5.31 със защитата на личните данни и PII, съхранението на записи, независимия преглед и съответствието с вътрешни политики. Също така съпоставя 5.31 с отчетността по GDPR, съответствието на веригата на доставки по NIS2, управлението на ИКТ риска по DORA, управлението по NIST CSF, програмните контроли по NIST SP 800-53 и надзора върху външното съответствие по COBIT 2019.

„Контрол 5.31 гарантира, че всички релевантни правни, регулаторни, законови и договорни изисквания, свързани с информационната сигурност, са идентифицирани, документирани и управлявани непрекъснато.“

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

Не отделяйте NIS2 от DORA, GDPR, доставчиците и облака

Доказателствата по NIS2 рядко съществуват изолирано.

NIS2 Article 21(2)(d) изисква сигурност на веригата на доставки, включително аспекти, свързани със сигурността, във взаимоотношенията с доставчици и доставчици на услуги. Article 21(3) изисква решенията за риска при доставчици да отчитат уязвимости, общо качество на продуктите, практики за киберсигурност, процедури за сигурна разработка и релевантни координирани оценки на риска във веригата на доставки на ЕС.

Приложение A на ISO 27001:2022 предоставя оперативния мост чрез A.5.19 до A.5.23. За SaaS и облачни организации тези контроли често определят дали доказателствата за регистрация са повърхностни или защитими.

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

Политиката за сигурност на трети страни и доставчици - МСП на Clarysec Политика за сигурност на трети страни и доставчици - МСП следователно трябва да бъде свързана с доказателствения пакет по NIS2. Готовността по отношение на доставчиците трябва да включва:

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

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

Сглобете едноседмичен доказателствен пакет по NIS2

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

Ден 1, класифицирайте субекта и услугите. Използвайте декларацията за обхвата на СУИС и регистъра на заинтересованите страни. Добавете меморандум за обхвата по NIS2, който идентифицира категориите от Приложение I или Приложение II, услугите в ЕС, държавите членки, клиентите, зависимостите, предположенията за размер и дали се прилагат DORA или секторни правила. Запишете несигурността в класификацията като риск, ако правното тълкуване не е окончателно.

Ден 2, актуализирайте регистъра на правните и регулаторните задължения. Добавете NIS2 Articles 20, 21, and 23, регистрационните изисквания по националното право, задълженията при нарушения по GDPR, задълженията по DORA, когато са релевантни, и ключови договорни изисквания за уведомяване. Съпоставете всяко задължение с политика, собственик, контрол, източник на доказателства и честота на преглед.

Ден 3, актуализирайте оценката на риска и третирането. Включете правно, регулаторно, оперативно, доставчици, финансово, репутационно и обществено въздействие в критериите за риск. Добавете рискове като неизвършване на регистрация, неправилна класификация на субекта, пропуснато 24-часово ранно предупреждение, недостъпни контакти на органите, прекъсване при доставчик, засягащо критични услуги, недостатъчен надзор от управителния орган и невъзможност за доказване на ефективността на контролите.

Ден 4, обновете SoA. Потвърдете релевантните за NIS2 контроли, включително A.5.5 контакт с органи, A.5.19 до A.5.23 контроли за доставчици и облак, A.5.24 до A.5.28 контроли за инциденти, A.5.29 сигурност при прекъсване, A.5.30 ИКТ готовност за непрекъсваемост на дейността, A.5.31 правни изисквания, A.5.34 поверителност, A.8.8 управление на уязвимостите, A.8.13 резервни копия, A.8.15 журналиране, A.8.16 дейности по мониторинг, A.8.24 криптография и контроли за сигурна разработка A.8.25 до A.8.32.

Ден 5, тествайте докладването на инциденти. Проведете tabletop упражнение: неправилна конфигурация в облака разкрива клиентски данни и прекъсва услуга в две държави членки. Стартирайте часовника. Може ли екипът да класифицира събитието, да оцени праговете по GDPR, NIS2, DORA, договори и клиентски задължения, да подготви 24-часово ранно предупреждение, да изготви 72-часово уведомление, да запази доказателства и да възложи анализ на първопричините?

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

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

Политиката за одит и мониторинг на съответствието за МСП на Clarysec Политика за одит и мониторинг на съответствието - МСП предвижда тази необходимост:

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

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

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

Това е целта: защитими доказателства преди да пристигне искането.

Подгответе се за различни одитни гледни точки

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

За ISO/IEC 27002:2022 контрол 5.5 одиторите обичайно очакват документирани контакти на органите, възложени отговорности, поддръжка на контактите, процедури за реагиране при инциденти и яснота, базирана на сценарии. Един прост одитен въпрос може да покаже зрелостта: „При ransomware кой се свързва с правоохранителните органи или националния CSIRT?“ Ако отговорът зависи от това някой да си спомни име, контролът не е готов.

Политиката за журналиране и мониторинг на Clarysec Политика за регистриране и мониторинг - МСП засилва очакването за доказателства:

„Журналите трябва да бъдат налични и разбираеми за външни одитори или регулатори при поискване“

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

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

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

Финален контролен списък за доказателства за регистрация по NIS2

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

• Документирайте анализа на обхвата по NIS2, включително обосновката по Приложение I или Приложение II, описанията на услугите, предположенията за размер, присъствието в държави членки и класификацията на субекта.
• Идентифицирайте дали DORA се прилага пряко или непряко чрез клиенти от финансовия сектор и договори за ИКТ услуги.
• Актуализирайте обхвата на СУИС, за да включите релевантните услуги, зависимости, външно възложени процеси и регулаторни интерфейси.
• Добавете NIS2, GDPR, DORA, секторни правила и договорни изисквания към регистъра на правните и регулаторните задължения.
• Съпоставете всяко задължение с политики, контроли, собственици, доказателства, честота на преглед и управленско докладване.
• Потвърдете одобрението и надзора от управителния орган върху мерките за управление на риска за киберсигурността.
• Поддържайте записи за обучение по киберсигурност на ръководството и служителите.
• Актуализирайте критериите за риск, така че да включват регулаторно въздействие, прекъсване на услуга, вреда за клиенти, трансгранично въздействие и зависимост от доставчици.
• Запишете свързаните с NIS2 рискове в регистъра на риска и ги свържете с планове за третиране.
• Актуализирайте SoA с релевантните за NIS2 контроли от Приложение A и статуса на внедряване.
• Поддържайте списъци с контакти на органите и процедури за уведомяване за CSIRT, компетентни органи, надзорни органи по защита на данните, финансови надзорни органи и правоохранителни органи.
• Тествайте работния поток за 24-часово ранно предупреждение, 72-часово уведомление, междинна актуализация и едномесечен окончателен доклад.
• Поддържайте доказателства за доставчици и облачни услуги, включително надлежна проверка, договори, права на одит, мониторинг, подизпълнители и планове за изход.
• Доказвайте ефективността на контролите чрез журнали, показатели, одити, информационни табла, резултати от тестове и коригиращи действия.
• Подгответе индекс на доказателствата, така че на всяко искане от регулатор, клиент или одитор да може да се отговори бързо.

Следващата стъпка с Clarysec

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

Clarysec помага на организациите да изградят тази история чрез Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls и практически набори от политики по ISO 27001:2022, които свързват правни задължения, третиране на риска, докладване на инциденти, сигурност на доставчиците, журналиране, мониторинг, одитни доказателства и управленска отчетност.

Направете преглед на пропуските в доказателствата по NIS2 спрямо текущата си СУИС. Започнете с меморандума за обхвата, правния регистър, регистъра на риска, SoA, списъка с контакти на органите, работния поток за докладване на инциденти, регистъра на доставчиците и папката с одитни доказателства. Ако тези артефакти са непълни или несвързани, Clarysec може да ви помогне да ги превърнете в доказателствен пакет, готов за регулаторен преглед, преди националният орган да го поиска.