Готовност за Акта на ЕС за киберсолидарност с ISO 27001

Инцидентът в 03:17, който превръща сътрудничеството в ЕС във ваш одитен проблем

В 03:17 във вторник сутрин Мария, директор по информационна сигурност (CISO) на InnovateCloud, гледа екран, пълен с предупреждения. Компанията ѝ е средно голям европейски SaaS доставчик, обслужващ логистични клиенти в Германия, Франция и Полша. Първото предупреждение изглежда като подозрителен привилегирован достъп в продукционен тенант. Десет минути по-късно доставчикът на управлявани услуги за сигурност докладва сходна дейност, засягаща още двама клиенти. До 04:00 SOC вижда извиквания към API от инфраструктура, която преди това е била свързвана с подготовка за ransomware.

InnovateCloud не е първоначалната цел. Изглежда, че ключов инфраструктурен доставчик попада в зоната на въздействие. Въздействието обаче вече е проблем на Мария.

Един засегнат клиент е германска банка, която изисква отговори по DORA. Друг е критичен доставчик в енергийния сектор, вече класифициран по националните правила за NIS2. Средата може да съдържа лични данни, но извличане на данни все още не е потвърдено. Екипът по сигурността иска незабавно да ограничи заплахата. Правният екип иска да знае дали е започнал да тече 24-часовият срок за ранно предупреждение по NIS2. Ръководителят по защита на личните данни пита дали може да се наложи уведомление за нарушение по GDPR. Управителният съвет иска да знае дали прекъсването може да се разпространи в няколко държави членки.

През 2026 г. това вече не е просто вътрешна криза.

Актът на ЕС за киберсолидарност променя оперативната реалност при мащабни и трансгранични киберинциденти. Той въвежда механизми за откриване, готовност и реагиране на равнище ЕС, включително European Cybersecurity Alert System, Cybersecurity Emergency Mechanism и EU Cybersecurity Reserve. Дори когато дадена организация никога не поиска пряко помощ от резерва, нейните доказателства, контакти с органи, договори с доставчици, хронологии на инциденти и комуникации с клиенти могат да станат част от по-широка европейска верига за реагиране.

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

Решението не е още една изолирана папка за „Акт за киберсолидарност“. Решението е система за управление на информационната сигурност (СУИС) по ISO/IEC 27001:2022, която създава доказателства еднократно и ги използва повторно за очакванията по NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT 2019.

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

Защо Актът на ЕС за киберсолидарност повишава стандарта за доказателства

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

Когато е възможно трансгранично въздействие, организацията може да трябва да координира действия с национални CSIRT, компетентни органи, секторни регулатори, органи за защита на данните, финансови надзорни органи, правоохранителни органи, клиенти, обработващи лични данни, доставчици и външни екипи за реагиране при инциденти. EU Cybersecurity Reserve добавя още едно измерение, защото предварително проверени частни доставчици могат да подкрепят готовността, реагирането и възстановяването. Това прави управлението на доставчици, правните правомощия, обработването на данни и запазването на доказателства още по-важни.

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

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

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

Финтех инцидент през 2026 г. следователно може да бъде координиран по надзорните канали на DORA, докато SaaS доставчикът или MSSP, който поддържа този финтех, може да попада под NIS2. Едно и също техническо събитие може да създаде различни задължения за докладване, очаквания за доказателства и договорни задължения за различните участници.

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

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

Моделът на Clarysec за доказателства: един инцидент, много задължения

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

Подходът на Clarysec свързва три актива:

1. Zenith Blueprint: 30-стъпкова пътна карта за одитори Zenith Blueprint, която превръща внедряването на ISO/IEC 27001:2022 в последователен път, готов за одит.
2. Zenith Controls: ръководство за съпоставка между рамки Zenith Controls, което съпоставя контролите по ISO/IEC 27002:2022 със свързани контроли, атрибути, оперативни способности, области на контролите за сигурност и очаквания за доказателства между различни рамки.
3. Шаблони за политики на Clarysec за реагиране при инциденти, събиране на доказателства, сигурност на доставчиците, журналиране, мониторинг и непрекъсваемост на дейността, адаптирани за корпоративни и SME среди.

В Zenith Blueprint, във фазата Controls in Action, Step 22 разглежда контрол 5.5 по ISO/IEC 27002:2022, контакт с органи. В него се посочва:

Контрол 5.5 гарантира, че организацията е подготвена да взаимодейства с външни органи, когато е необходимо — не реактивно или в паника, а чрез предварително определени, структурирани и добре разбирани канали.

Същият раздел задава въпроса, на който всеки CISO трябва да отговори преди кризата:

Ако вашата организация стане цел на кибератака, участва в нарушение на сигурността на данните или е обект на разследване, кой би се свързал с органите? Как би знаел какво да каже? При какви условия би бил иницииран такъв контакт?

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

Zenith Controls третира контрол 5.5 по ISO/IEC 27002:2022, контакт с органи, като превантивен и коригиращ, свързан с поверителност, цялостност и наличност, и съгласуван с концепциите Identify, Protect, Respond и Recover. Той свързва 5.5 с планиране и подготовка за управление на инциденти, докладване на събития, разузнаване за заплахи, групи със специален интерес и реагиране при инциденти.

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

За обработването на доказателства контрол 5.28 по ISO/IEC 27002:2022, събиране на доказателства, е особено важен. Zenith Controls го свързва с реагиране при инциденти, журналиране, мониторинг и докладване на събития. При сериозен трансграничен инцидент именно тук техническото разследване става защитимо.

Съпоставяне на готовността за Акта за киберсолидарност с доказателства по ISO 27001

Актът на ЕС за киберсолидарност създава среда за готовност и координация. ISO/IEC 27001:2022 предоставя двигателя за доказателства. NIS2, DORA и GDPR определят много конкретни очаквания за докладване, управление и защита.

Забележете какво липсва: отделен силоз за съответствие. Същите доказателства, които подкрепят сертификацията по ISO/IEC 27001:2022, могат да подкрепят отчетността на ръководството по NIS2, управлението на ИКТ риска по DORA, отчетността за сигурността по GDPR, комуникационните резултати по NIST CSF и очакванията за уверение по COBIT 2019.

NIS2: часовникът за докладване започва, когато започне узнаването

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

Article 23 изисква съществени и важни субекти да уведомят своя CSIRT или компетентен орган без неоправдано забавяне за значими инциденти, засягащи предоставянето на услуги. Ранното предупреждение трябва да бъде подадено без неоправдано забавяне и не по-късно от 24 часа след узнаване за значимия инцидент. Когато е приложимо, то следва да посочва дали се подозира злонамерено или незаконно действие и дали е възможно трансгранично въздействие.

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

Ето защо реагирането при инциденти не може да започва с празен документ.

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

NIS2 Article 23 (уведомление в срок от 24 часа от узнаване за инцидента)

SME Политика за реагиране при инциденти - SME Политика за реагиране при инциденти - SME въвежда същата логика за сроковете в практическо управление:

„Сроковете за реагиране, включително възстановяване на данни и задължения за уведомяване, трябва да бъдат документирани и съгласувани с правните изисквания, като например изискването по GDPR за уведомяване за нарушение на сигурността на личните данни в срок от 72 часа.“

От Политика за реагиране при инциденти - SME, раздел „Изисквания за управление“, клауза 5.3.2.

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

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

От Политика за реагиране при инциденти - SME, раздел „Третиране на риска и изключения“, клауза 7.4.1.

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

Записът за инцидента трябва да улавя:

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

Най-добрият момент за проектиране на тези полета е преди 03:17.

DORA: когато клиентът е регулиран, но доставчикът държи журналите

DORA променя разговора с доставчиците. Финансовите субекти трябва да управляват ИКТ риска от трети страни като част от своята рамка за управление на ИКТ риска. Външното възлагане на ИКТ услуги не прехвърля регулаторната отговорност извън финансовия субект.

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

Да се върнем към инцидента на Мария. Германската банка е регулирана по DORA. InnovateCloud предоставя SaaS услуги. MSSP открива подозрителна дейност. Доставчикът на облачна инфраструктура държи част от ключовите одитни журнали. Подизпълнител управлява част от телеметричния пайплайн. Банката остава отговорна, но не може да класифицира и докладва качествено без доказателства от доставчиците.

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

Договорите с доставчици трябва да включват:

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

Договорите трябва да включват задължителни клаузи, обхващащи:

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

Zenith Blueprint, във фазата Controls in Action, Step 23, дава пътя за внедряване:

Съставете пълен списък на текущите доставчици и доставчици на услуги (5.19) и ги класифицирайте въз основа на достъпа до системи, данни или оперативен контрол. За всеки класифициран доставчик проверете дали очакванията за сигурност са ясно включени в договорите (5.20), включително поверителност, достъп, докладване на инциденти и задължения по съответствие.

Продължава с риска надолу по веригата:

За всеки критичен доставчик установете дали използва подизпълнители (sub-processors), които могат да имат достъп до вашите данни или системи. Документирайте как вашите изисквания за информационна сигурност се прехвърлят към тези страни — чрез договорните условия на вашия доставчик или чрез ваши преки клаузи.

Това е готовност и за Cybersecurity Reserve. Ако външен доставчик за реагиране влезе във вашата среда по време на извънредна ситуация, трябва да знаете правното основание, обхвата на достъпа, правилата за доказателства, задълженията за обработване на данни, пътя за координация с органи и условията за изход. DORA прави това изрично за финансовите субекти. NIS2 го прави релевантно за съществени и важни субекти. ISO/IEC 27001:2022 го прави одитируемо.

GDPR: въпросът за нарушението вътре в киберкризата

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

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

По време на инцидента в 03:17 екипът на Мария трябва да попита:

• Били ли са лични данни достъпени, разкрити, променени, загубени или унищожени?
• InnovateCloud администратор ли е, обработващ лични данни ли е или и двете за засегнатите данни?
• Засегнати ли са специални категории лични данни?
• Кои клиенти или физически лица са засегнати?
• Достатъчни ли са журналите за оценка на обхвата?
• Текат ли задълженията за уведомяване по GDPR паралелно със задълженията по NIS2 или DORA?

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

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

Предупрежденията с висок приоритет трябва да бъдат ескалирани към управителя и координатора по защита на личните данни в срок от 24 часа

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

Изграждане на 24-часов пакет с доказателства за трансграничен инцидент

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

Сценарий

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

Стъпка 1: Отворете запис за инцидента

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

Свържете това с контроли 5.24, 5.25 и 5.26 по ISO/IEC 27002:2022 и с контроли A.5.24, A.5.25 и A.5.26 от Приложение A на ISO/IEC 27001:2022.

Стъпка 2: Задействайте работния процес за решение относно органите

Използвайте матрицата за контакт с органи, изисквана от Zenith Blueprint Step 22. Определете кои органи може да са релевантни: национален CSIRT, орган за защита на данните, финансов регулатор, правоохранителни органи и секторен регулатор.

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

Стъпка 3: Запазете доказателства преди значими действия за отстраняване

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

Всички събрани доказателства трябва да бъдат уникално идентифицирани, етикетирани и съхранявани в сигурно хранилище със:

SME Политика за събиране на доказателства и форензика - SME Политика за събиране на доказателства и форензика - SME дава същата дисциплина в по-проста форма:

„Всеки елемент от цифрови доказателства трябва да бъде регистриран със:“

От Политика за събиране на доказателства и форензика - SME, раздел „Изисквания за управление“, клауза 5.2.1.

За tabletop упражнението съберете примерни доказателствени записи: експорт на SIEM предупреждение, журнали от доставчик на идентичност, записи за привилегировани сесии, моментна снимка на крайна точка, журнали на защитната стена, облачни одитни журнали, бележки за въздействието върху клиенти и одобрения на комуникации.

Стъпка 4: Активирайте съдействие от доставчици

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

Това пряко подкрепя изискванията на DORA за ИКТ риск от трети страни и очакванията на NIS2 за сигурност на веригата на доставки.

Стъпка 5: Подгответе три комуникации

Подгответе три комуникации от една и съща фактическа база:

Стъпка 6: Завършете с извлечени поуки

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

Zenith Blueprint, във фазата Controls in Action, Step 23, инструктира организациите да валидират способностите си за инциденти по следния начин:

Изберете скорошно събитие или проведете tabletop упражнение, за да валидирате плана си. Уловете и регистрирайте всички решения, роли и комуникации (5.26) и актуализирайте плана с извлечените поуки (5.27). Потвърдете, че са въведени процедури за запазване на форензични доказателства (5.28), включително моментни снимки на журнали, резервни копия и сигурна изолация на засегнатите системи.

Този параграф е готов за одит дневен ред за упражнение.

Журналиране: разликата между координация и спекулация

Координацията при трансгранични инциденти се проваля, когато всички имат мнения, но никой няма времеви маркери.

Zenith Blueprint, във фазата Controls in Action, Step 19, го формулира ясно:

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

Продължава:

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

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

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

Непрекъсваемост на дейността и сигурни кризисни операции

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

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

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

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

Плановете трябва да обхващат:

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

Контроли 5.29 и 5.30 по ISO/IEC 27002:2022 са централни тук. Контрол 5.29 разглежда информационната сигурност по време на прекъсване. Контрол 5.30 разглежда ИКТ готовността за непрекъсваемост на дейността. В Zenith Controls планирането на инциденти по 5.24 е свързано със сигурност по време на прекъсване и по-широко планиране на непрекъсваемостта. Това е особено релевантно, когато нормалните канали са недостъпни, системите за идентичност са деградирали или кризисните екипи трябва да координират с органи чрез защитени аварийни комуникации.

Карта на съответствието между рамки: NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT 2019

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

Методът за текущ и целеви профил на NIST CSF 2.0 е особено полезен за организации, които все още не са достатъчно зрели за напълно интегрирана GRC платформа. Той насърчава организациите да определят обхват на профил, да събират входни данни като политики, приоритети на корпоративния риск, анализи на въздействието върху бизнеса, изисквания, стандарти, процедури, предпазни мерки и роли, след което да анализират пропуските и да създадат приоритизиран план за действие. Това е близо до практически спринт за готовност за Акта за киберсолидарност: текущи доказателства, целеви задължения, план за пропуски, собственици, дати и одитна следа.

Одиторите по COBIT 2019 и в стила на ISACA обикновено питат дали целите на управлението имат собственици, измерват се и се наблюдават. Те няма да се задоволят с „SOC се занимава с това“. Ще попитат как управленските органи одобряват мерките за риска, как се докладва резултатността, как се управлява рискът от трети страни, как се приемат изключенията и как се проследяват коригиращите действия.

Как одиторите ще тестват същия инцидент

Същият инцидент в 03:17 поражда различни одитни въпроси според мандата на оценяващия.

Одитор по ISO/IEC 27001:2022 ще започне със СУИС. Той ще попита дали процесът за инциденти е в обхвата, дали изискванията на заинтересованите страни включват NIS2, DORA, GDPR и договори, дали оценката на риска е разгледала трансгранични сценарии и сценарии с доставчици, дали контролите от Приложение A са избрани в Декларацията за приложимост и дали оперативните записи доказват, че процесът е бил следван.

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

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

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

Оценител по NIST CSF 2.0 ще преведе събитието в резултати Govern, Identify, Protect, Detect, Respond и Recover. Той ще търси очаквания на заинтересованите страни, правни задължения, апетит за риск, управление на доставчици, журналиране, мониторинг, изпълнение на реагирането, комуникации и валидация на възстановяването.

Одитор по COBIT 2019 или ISACA ще се фокусира върху ефективността на управлението и системата за управление: собственост, права за вземане на решения, показатели, приемане на риска, резултатност на процесите, уверение и непрекъснато подобрение.

Тук Zenith Controls е полезен като компас за съответствие между рамки. Той не преименува официални контроли и не създава паралелна контролна рамка. Показва как контроли по ISO/IEC 27002:2022 като 5.5, 5.24 и 5.28 се свързват с оперативни способности, свързани контроли и доказателства, релевантни за одит.

Какво трябва да направят CISO сега за готовност през 2026 г.

Ако се подготвяте за оперативната реалност на Акта на ЕС за киберсолидарност, започнете с доказателства, а не със слогани.

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

Второ, проведете tabletop упражнение за трансграничен инцидент. Използвайте сценарий, който включва доставчик, повече от една държава членка, възможна експозиция на лични данни и регулиран финансов клиент. Ограничете първите 24 часа във времева рамка.

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

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

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

Шесто, включете управителния съвет в упражнението. NIS2 и DORA повишават отчетността на ръководството. Клаузите за лидерство в ISO/IEC 27001:2022 правят това одитируемо. Съвет, който никога не е виждал 24-часов срок за киберуведомление, не е готов за трансгранична криза.

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

Бъдещето на киберсигурността в ЕС е сътрудничество и доказано доверие. Организации, които третират NIS2 и DORA като изолирани контролни списъци, ще срещнат трудности при трансгранични инциденти. Организации, които изграждат подкрепени с доказателства оперативни системи по ISO/IEC 27001:2022, ще могат уверено да отговарят на регулатори, клиенти, одитори и екипи за кризисно реагиране.

Clarysec помага на CISO, мениджъри по съответствие, одитори и собственици на бизнеса да превърнат киберрегулациите на ЕС в оперативни доказателства, готови за одит, чрез:

• Zenith Blueprint: 30-стъпкова пътна карта за одитори за структурирано внедряване на ISO/IEC 27001:2022 и последователност за одит.
• Zenith Controls: ръководство за съпоставка между рамки за съпоставяне на контролите за инциденти, органи, доставчици, доказателства, журналиране и непрекъсваемост между рамки.
• Шаблони за политики на Clarysec, включително Политика за реагиране при инциденти, Политика за събиране на доказателства и форензика, Политика за сигурност на трети страни и доставчици, Политика за непрекъсваемост на дейността и аварийно възстановяване, както и SME версии, когато пропорционалността има значение.

Най-добрият момент за подготовка за координация при трансгранични инциденти е преди предупреждението в 03:17. Вторият най-добър момент е днес.

Започнете с преглед на готовността с Clarysec, изтеглете релевантния набор от политики или поискайте демонстрация как Zenith Blueprint и Zenith Controls могат да помогнат на вашата СУИС да създава доказателствата, които киберустойчивостта през 2026 г. ще изисква.