Апетит към ИКТ риск по DORA: ръководство за одобрение от управителния орган за 2026 г.

08:15 е във вторник, а главният директор по информационна сигурност (CISO) на средно голяма компания за платежни технологии стои пред заседателната зала с три отворени документа на таблет.

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

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

„Какво ниво на ИКТ риск всъщност сме се съгласили да приемем?“

В залата настъпва тишина, защото компанията има оценки на риска, но няма одобрен от управителния орган апетит към ИКТ риск. Има оценки на въздействието, но няма измерими прагове на толеранс. Има срещи за ескалация, но няма формално задействащо условие, което да определя кога киберрискът става решение на управителния орган. Има приети остатъчни рискове, но част от тях са обосновани като „бизнес решения“ без ясна връзка с критериите за риск, пропорционалността по GDPR Article 32, очакванията за толеранс по DORA или управленската отчетност по NIS2.

Тази празнина става все по-видима през 2026 г. DORA се прилага от 17 януари 2025 г. и изисква финансовите субекти да поддържат рамка за управление и контрол на ИКТ риска, включително отговорност на управителния орган за рамката за управление на ИКТ риска, стратегията за цифрова оперативна устойчивост и толеранса към ИКТ риск. NIS2 изисква управителните органи да одобряват мерките за управление на рисковете за киберсигурността и да наблюдават внедряването им. GDPR Article 32 изисква подходящи технически и организационни мерки за сигурност, основани на риска. ISO/IEC 27001:2022 предоставя механиката на системата за управление: контекст, заинтересовани страни, критерии за риск, планове за третиране, документирана информация и преглед от ръководството.

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

Това ръководство обяснява как да изградите този мост чрез Zenith Blueprint: 30-стъпкова пътна карта за одитора, Risk Management Policy на Clarysec, Risk Management Policy-sme на Clarysec и Zenith Controls: ръководство за кръстосано съответствие.

Защо регистрите на рисковете не са апетит към риск

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

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

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

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

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

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

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

Използвайте ISO/IEC 27001:2022 като операционна система

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

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

Клаузи 5.1 до 5.3 изискват ангажираност на ръководството, съгласуване на политиките, ресурси, отговорности и докладване на резултатността на СУИС пред висшето ръководство. Клаузи 6.1.1 до 6.1.3 изискват риск-базирано планиране, документиран процес за оценяване на риска, критерии за приемане на риска, последователни критерии за оценяване, собственици на риска, сравнение спрямо критериите за риск, планиране на третирането, Декларация за приложимост и одобрение на остатъчния риск.

Това е основата за толеранса към ИКТ риск по DORA.

В етапа „Управление на риска“ стъпка 10 от Zenith Blueprint указва на организациите да дефинират критериите за риск преди оценяването на рисковете:

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

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

„Всеки риск, който може да доведе до несъответствие с приложимите закони (GDPR и др.), не е приемлив и трябва да бъде смекчен.“

Zenith Blueprint също предоставя практически насоки за скалиране на въздействието:

„При дефиниране на въздействието е разумно нивата да се свържат с конкретния мащаб на вашия бизнес. Например: „Съществено финансово въздействие = загуба > $100k“ (адаптирайте според вашия контекст). Вземете предвид и регулаторното въздействие: например нарушение на сигурността на личните данни може автоматично да бъде „Съществено“ или „Тежко“ поради глобите по GDPR и изискванията за уведомяване, дори когато пряката финансова загуба е неясна. По сходен начин, ако попадате в обхвата на NIS2 (съществени услуги), инцидент, причиняващ прекъсване на услугата, може да бъде поне „Съществен“ поради правните последици. Включете такива съображения във вашите дефиниции.“

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

Модел, готов за управителния орган, трябва да разделя четири слоя:

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

Декларация за апетит към ИКТ риск по DORA, готова за управителния орган

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

Практическа декларация на високо ниво може да гласи:

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

След това тази декларация се нуждае от измерими прагове на толеранс и задействащи условия за ескалация.

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

Risk Management Policy на Clarysec подкрепя този модел на управление. Корпоративната политика посочва:

„Одобрява рамката за управление на риска и дефинира приемливия апетит към риск и прагове на толеранс.“

Клауза 6.2.1 прави изискването за измерване изрично:

„Рисковете се оценяват по вероятност и въздействие чрез стандартна матрица на риска с ясно дефинирани скали за точкова оценка.“

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

„Рисковете, приети без третиране, трябва да бъдат обосновани писмено, свързани с апетита към риск на организацията и одобрени на подходящото ниво.“

За МСП Risk Management Policy-sme запазва същия принцип на управление в по-лека форма:

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

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

„Високите рискове трябва да бъдат ескалирани към управителя (GM) за решение.“

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

GDPR Article 32 променя разговора за риска

GDPR Article 32 често се третира като техническа клауза за сигурност. От гледна точка на управлението той е и клауза за апетит към риск.

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

Това влияе върху апетита към ИКТ риск по три начина.

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

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

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

Risk Management Policy на Clarysec изрично свързва това:

„Article 32: изисква риск-базиран подход към мерките за сигурност, изпълняван чрез оценки на риска, основани на въздействието, и избор на контроли.“

Това е оперативната връзка, която одиторите търсят: изискване по Article 32, оценка на риска, оценяване на нивото на риска, план за третиране, избор на контроли, остатъчен риск и одобрение.

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

Одобрената от управителния орган декларация за апетит става силна, когато е съпоставена с контроли. Zenith Controls действа като ръководство на Clarysec за кръстосано съответствие и помага на екипите да използват повторно доказателства в ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF и уверение в стил COBIT.

Три области на контроли от ISO/IEC 27002:2022 са особено важни:

Това не е упражнение по съпоставяне на хартия. То променя начина, по който се вземат решения.

Ако собственик на бизнес поиска да се приеме забавено внедряване на MFA за администратори, Zenith Controls помага на CISO да покаже защо това не е само въпрос на контрол на достъпа. То засяга управлението на политиките, отговорността на ръководството, правните и регулаторните изисквания, сигурността на обработването по GDPR, управлението на ИКТ риска по DORA, мерките за киберсигурност по NIS2, въздействието на инцидентите и доказателствата за одит.

Ако продуктов екип иска да стартира на нов пазар в ЕС чрез нова облачна услуга, контрол 5.31 на ISO/IEC 27002:2022 включва прегледа на правните и регулаторните изисквания в обхвата на СУИС. Клауза 4.2 на ISO/IEC 27001:2022 изисква да бъдат идентифицирани изискванията на заинтересованите страни, включително правни, регулаторни и договорни задължения. Клауза 8.1 изисква оперативно планиране и контрол, включително контрол на външно предоставяни процеси, продукти или услуги, релевантни за СУИС.

Целта е единен език на риска, а не отделни диалекти на съответствието.

Работен поток за одобрение: кой какво решава

CISO може да предложи апетит към ИКТ риск, но управителният орган трябва да го притежава. Тази собственост се нуждае от работен поток.

Това също е съгласувано с NIST CSF 2.0. Функцията GOVERN, особено GV.RM, очаква договорени цели за управление на риска, декларации за апетит и толеранс към риск, рискови дейности, интегрирани в корпоративното управление на риска, дефинирани опции за реакция на риска, комуникационни линии и стандартизирани методи за изчисляване, документиране, категоризиране и приоритизиране на рисковете за киберсигурността. GV.RR очаква отчетност на ръководството, роли, правомощия и ресурси, съгласувани със стратегията за риска. GV.PO очаква политиките да бъдат установени, комуникирани, прилагани, преглеждани и актуализирани.

Специалистите по уверение в стил COBIT 19 и ISACA ще попитат дали апетитът към риск е интегриран в корпоративното управление на информацията и технологиите, а не просто приложен като анекс към киберполитика.

Изградете пакет за апетит към ИКТ риск в една работна сесия

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

Стъпка 1: съберете правилните входни данни

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

Това е съгласувано с клаузи 4, 6 и 8 на ISO/IEC 27001:2022 и с методите за профили по NIST CSF, които започват с бизнес приоритети, приоритети на риска, изисквания, предпазни мерки и роли.

Стъпка 2: дефинирайте скали за въздействие, които включват регулацията

Използвайки стъпка 10 от Zenith Blueprint, дефинирайте вероятност и въздействие на бизнес език. Включете финансова загуба, оперативно прекъсване, въздействие върху клиентите, репутационен ущърб, правно и регулаторно въздействие, вреда за субектите на данни и въздействие върху критични функции.

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

Стъпка 3: напишете апетит по области

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

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

Стъпка 4: свържете третирането с Декларацията за приложимост

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

„Решенията за третиране на риска и SoA трябва да бъдат прегледани и одобрени от висшето ръководство.“

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

Стъпка 5: запишете приемането със срок и условия

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

• Идентификатор на риска и собственик
• Бизнес обосновка
• Препратка към декларацията за апетит
• Засегнат праг на толеранс
• Правен и регулаторен анализ
• Компенсиращи контроли
• Дата на изтичане или преглед
• Одобряващ
• Местоположение на доказателствата
• Условие за повторно отваряне на решението

Risk Management Policy-sme посочва:

„Всяко решение за приемане или отлагане на третиране на висок или среден риск трябва да бъде документирано в регистъра на рисковете. Тази документация трябва да включва:“

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

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

Апетитът към риск става реален по време на инциденти.

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

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

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

Декларацията за апетит трябва да дефинира праговете за ескалация преди настъпване на инцидента.

Контролите от Annex A относно планиране при инциденти, оценка на събития по информационна сигурност, реагиране при инциденти, извличане на поуки от инциденти, събиране на доказателства, поддържане на информационната сигурност по време на прекъсване и ИКТ готовност за непрекъснатост на дейността подкрепят тези прагове. Резултатите по NIST CSF в IDENTIFY, PROTECT, DETECT, RESPOND и RECOVER подкрепят същия оперативен модел, включително резервни копия, мониторинг, обявяване на инцидент, ескалация, анализ на първопричините, комуникация със заинтересованите страни и проверка на възстановяването.

Толерансът към доставчици и облачни услуги, който управителните органи често пропускат

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

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

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

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

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

Как одиторите ще тестват вашия апетит към ИКТ риск

Силната декларация за апетит е проектирана с мисъл за одита.

Стъпка 28 от Zenith Blueprint, във фазата „Одит, преглед и подобрение“, подсилва слоя на прегледа от ръководството. Тя инструктира организациите да събират входни данни като промени във външни и вътрешни обстоятелства, резултатност на СУИС, резултати от одити, мониторинг и измерване, инциденти, несъответствия, възможности за подобрение и нужди от ресурси. Тя също посочва, че прегледът от ръководството трябва да води до решения и действия, а не само до презентации.

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

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

Чести модели на неуспех в работата по готовност през 2026 г.

В проекти по DORA, NIS2, GDPR и ISO/IEC 27001:2022 едни и същи слабости се появяват многократно:

• Апетит без прагове, при който управителният орган одобрява декларация, но никой не може да каже кога тя е нарушена.
• Прагове без правомощия, при които съществуват нива на тежест, но собствениците на риска могат да приемат изключения без одобрение от висшето ръководство.
• Правен риск извън модела за точкова оценка, при който GDPR, DORA, NIS2 и договорите са изброени отделно, но не са вградени в критериите за въздействие.
• Липсващ толеранс към доставчици в пакета за управителния орган, въпреки че критичните ИКТ зависимости са известни на снабдяването или ИТ.
• Преглед от ръководството като театър, при който се представят слайдове, но решенията, действията, нуждите от ресурси и приемането на рискове не се документират.
• Фрагментация на доказателствата за одит, при която политики, регистри, KRI, доклади за инциденти, прегледи на доставчици и протоколи на управителния орган съществуват на различни места без кръстосана препратка.

Подходът на Clarysec е създаден, за да премахне тези празнини. Zenith Blueprint предоставя поетапния път за внедряване. Risk Management Policy и Risk Management Policy-sme предоставят клаузи за управление, мащабирани за корпоративни и МСП среди. Zenith Controls съпоставя гръбнака на контролите през политиката за информационна сигурност, отговорността на ръководството и правните или регулаторните изисквания, като прави доказателствата повторно използваеми в ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF и уверение в стил COBIT.

Превърнете намерението на управителния орган в одитируемо управление на ИКТ риска

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

Практическа следваща стъпка е провеждането на фокусиран семинар за апетит към ИКТ риск чрез инструментариума на Clarysec:

1. Използвайте стъпка 10 от Zenith Blueprint, за да дефинирате критерии за риск и скали за въздействие.
2. Използвайте стъпка 13 от Zenith Blueprint, за да свържете опциите за третиране, остатъчния риск и одобрението на Декларацията за приложимост.
3. Използвайте стъпка 14 от Zenith Blueprint, за да направите кръстосани препратки към задълженията по GDPR, NIS2 и DORA.
4. Използвайте стъпка 28 от Zenith Blueprint, за да включите апетита, KRI, приетите рискове и решенията за ресурси в прегледа от ръководството.
5. Приложете Risk Management Policy или Risk Management Policy-sme, за да формализирате правилата за одобрение и приемане.
6. Използвайте Zenith Controls, за да съпоставите управленските контроли с доказателства за одит и очаквания за кръстосано съответствие.

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