Количествена оценка на киберриска за NIS2 и DORA

Заседанието на ръководния орган, на което „висок риск“ вече не беше достатъчно
08:15 е във вторник. CISO на бързо растяща финтех компания стои пред заседателната зала с три версии на една и съща история за киберриска.
Първата версия е позната: ransomware е „висок“, прекъсване на облачна услуга е „високо“, компрометиране на доставчик е „средно“, неправомерно използване на привилегирован достъп е „високо“. Това е защитимо, съгласувано с текущия регистър на риска и почти безполезно за решението, което ръководният орган трябва да вземе.
Втората версия е техническа пътна карта: внедряване на неизменяеми резервни копия, подобряване на контролите за идентичност, финансиране на тестване на устойчивостта, засилване на мониторинга на доставчиците и разширяване на обхвата на логването. Това е разумно, но финансовият директор задава въпроса, който променя срещата: „Кое от тези действия намалява най-много бизнес риска за всяко евро?“
Третата версия променя разговора.
12-часово прекъсване на платформата за оркестрация на плащанията се оценява на €620,000 общо оперативно, договорно и приходно въздействие. Текущата годишна експозиция се оценява на €186,000. Пакет за устойчивост на стойност €74,000 може да намали очакваната годишна загуба до приблизително €62,000. Остатъчната експозиция все още е над толеранса, защото услугата поддържа критична или важна функция, експозицията за уведомяване на клиенти остава съществена, а зависимостта от трети страни е висока.
Сега ръководният орган не обсъжда цветове. Той обсъжда финансова експозиция, толеранс към риск, регулаторна отчетност и инвестиционни приоритети.
Това е количествената оценка на киберриска през 2026 г. Тя не е математически театър. Не претендира, че киберсъбитията могат да се прогнозират с пълна точност. Тя е дисциплинираното превръщане на „това е червено“ в „това е вероятната финансова експозиция, това е нивото на увереност, това е регулаторното последствие, това е решението за третиране и това е одитната следа“.
За CISO, мениджъри по съответствие, одитори и собственици на бизнес тази промяна на практика става задължителна. ISO/IEC 27001:2022 изисква документиран, последователен и съпоставим процес за оценка и третиране на риска. NIS2 прехвърля риска за киберсигурността към одобрение, надзор, обучение и отговорност на ръководния орган. DORA поставя управлението на ИКТ риска, тестването на устойчивостта, класификацията на инцидентите, риска от трети страни и отчетността на ръководството в центъра за финансовите субекти. NIST CSF 2.0 предоставя на ръководството управленски език за апетит за риск, приоритизация и надзор. GDPR добавя отчетност, когато са засегнати лични данни.
Проблемът не е, че организациите нямат регистри на риска. Проблемът е, че много регистри на риска не могат да обяснят финансовия ефект, приоритетите, отчетността пред ръководния орган или одитните доказателства.
Подходът на Clarysec затваря тази празнина, като обединява Zenith Blueprint: 30-стъпкова пътна карта за одитора Zenith Blueprint, политиките на Clarysec и Zenith Controls: Ръководство за кръстосано съответствие Zenith Controls в един практически модел за доказателства: количествено оценете същественото, съпоставете го с контролите, покажете кой го е приел и докажете, че третирането е проработило.
Защо качествените регистри на риска вече не са достатъчни
Качествената оценка на риска все още е важна. Ясна матрица на вероятност и въздействие помага на екипите да приоритизират, когато данните са непълни, особено при широк обхват на СУИС. Проблемът започва, когато организацията спре дотам.
Ръководният орган може да разбере, че даден риск е „висок“, но не може лесно да сравни три „високи“ риска, които се конкурират за един и същ бюджет. Най-високият приоритет ли е сценарият с ransomware, прекъсването на облачна услуга, рискът от концентрация при доставчик или слабостта в привилегирования достъп? Отговорът зависи от финансовата експозиция, регулаторната сериозност, въздействието върху клиентите, договорните задължения, критичността на услугата и остатъчния риск след третиране.
Затова количествената оценка на киберриска работи най-добре като хибриден модел. Не оценявайте количествено всеки незначителен въпрос. Използвайте качествено точкуване за целия регистър, след което добавете финансов анализ за рисковете, които изискват управленски решения, одобрение на инвестиции, договорни действия, прехвърляне на риска или надзор от ръководния орган.
Корпоративната Политика за управление на риска на Clarysec Политика за управление на риска изрично подкрепя това. В раздел „Изисквания за прилагане на политиката“, клауза 6.2.3, тя посочва:
„Могат да се прилагат както качествени, така и количествени методи в зависимост от категорията на риска и наличността на информация.“
Тази клауза е важна, защото предотвратява често срещан провал: фалшива точност. Зрелите организации не налагат финансово моделиране върху всеки малък риск. Те го прилагат там, където решението го изисква.
За МСП основата може да остане проста. Политиката за управление на риска за МСП на Clarysec Политика за управление на риска - МСП, раздел „Изисквания за управление“, клауза 5.1.2, посочва:
„Всеки запис за риск трябва да включва: описание, вероятност, въздействие, оценка, собственик и план за третиране.“
Подобрението не е да се замени тази структура. Подобрението е най-важните записи да се обогатят с финансови оценки, особено когато са засегнати престой, регулирани услуги, лични данни, зависимост от облачни услуги, външно възлагане на ИКТ или критични ангажименти към клиенти.
Управленската промяна: киберрискът вече е артефакт за ръководния орган
Количественото изразяване на киберриска не е само финансово упражнение. То е доказателство за управление.
Съгласно ISO/IEC 27001:2022 организацията трябва да определи контекста, заинтересованите страни, правните и договорните изисквания, обхвата, интерфейсите и зависимостите. Тя трябва да дефинира процес за оценка на риска за информационната сигурност, който да дава последователни, валидни и съпоставими резултати. Тя трябва да идентифицира рисковете за поверителност, цялостност и наличност, да определи собственици на риска, да оцени последиците и вероятността, да определи нивата на риска и да приоритизира рисковете. След това трябва да избере варианти за третиране, да определи контроли, да ги сравни с Приложение A, да изготви Декларация за приложимост, да получи одобрение от собственика на риска и да съхрани документирана информация.
Това означава, че регистърът на риска не е частна електронна таблица на екипа по сигурност. Той е запис на СУИС, който свързва ръководството, избора на контроли, отчетността за третирането и прегледа от ръководството.
NIS2 повишава очакването още повече. Ръководните органи на съществени и важни субекти трябва да одобряват мерките за управление на риска за киберсигурността, да упражняват надзор върху внедряването и да получават обучение, за да разбират рисковете и да оценяват практиките за киберсигурност. NIS2 Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, като се вземат предвид съвременното състояние на технологиите, разходите за внедряване, рисковата експозиция, размерът на субекта, вероятността, тежестта и общественото и икономическото въздействие.
Тази фраза — „обществено и икономическо въздействие“ — е мястото, където финансовото количествено изразяване на киберриска става особено силно. Доставчик, който поддържа облачни услуги, центрове за данни, DNS, доверителни услуги, управлявани услуги, управлявани услуги за сигурност, цифрова инфраструктура, онлайн пазари или други обхванати сектори, може да трябва да покаже не само че контролите съществуват, но и защо са пропорционални на експозицията.
За финансовите субекти DORA се прилага от 17 януари 2025 г. и се превръща в секторно специфичния режим за цифрова оперативна устойчивост. Тя обхваща управление на ИКТ риска, докладване на съществени ИКТ-свързани инциденти, тестване на цифровата оперативна устойчивост, споделяне на информация за киберзаплахи, ИКТ риск от трети страни и надзор върху критични външни доставчици на ИКТ услуги. За финансови субекти, които са идентифицирани и по националното транспониране на NIS2, DORA действа като секторно специфичен правен акт на Съюза за съответните въпроси, свързани с управление на ИКТ риска и докладване на инциденти.
На практика финтех компанията не се нуждае от пет несвързани рамки за риск. Тя се нуждае от един интегриран модел на риска, който показва кой режим се прилага, какви зависимости съществуват, каква финансова експозиция е вероятна и как ръководството е одобрило и наблюдавало третирането.
GDPR добавя още един слой. Ако са засегнати лични данни, киберсъбитието може да се превърне в нарушение на сигурността на личните данни, а не само в оперативен инцидент. Моделът на риска трябва да идентифицира контекста на обработване, ролята на администратор или обработващ лични данни, категориите данни, специалните категории данни, когато е приложимо, мерките за сигурност, логиката за оценка на нарушението и последиците за уведомяване.
От топлинна карта към евро: практическият хибриден модел
Правилният въпрос не е: „Трябва ли да заменим качествената оценка на риска?“ Правилният въпрос е: „Кои рискове заслужават финансово количествено изразяване?“
Zenith Blueprint, фаза „Управление на риска“, стъпка 12, „Методи за оценка на риска: качествени и количествени“, дава прагматичен отговор:
„Количествената оценка на риска се стреми да оцени риска в числово изражение (например очаквана годишна загуба във валута). Това често включва:
✓ Събиране на исторически данни за инциденти (например колко често настъпва нарушение и каква е средната цена). ✓ Използване на модели като очаквана годишна загуба (ALE = загуба при еднократно събитие × годишна честота на настъпване) или рамки като FAIR (Factor Analysis of Information Risk) за по-сложен анализ.“
Същата стъпка предупреждава, че чисто количественият анализ може да бъде труден за МСП, защото историческите данни може да са ограничени, а процесът — ресурсоемък. Практическият отговор е „лека количествена“ оценка за най-значимите рискове.
| Елемент | Практическо значение | Пример |
|---|---|---|
| Загуба при еднократно събитие | Оценено въздействие, ако сценарият настъпи веднъж | €620,000 за 12-часово прекъсване на платежна платформа |
| Годишна честота на настъпване | Оценена честота за година | 0.3, което означава приблизително веднъж на 3.3 години |
| Очаквана годишна загуба | Загуба при еднократно събитие, умножена по годишната честота на настъпване | €186,000 очаквана годишна експозиция |
| Разход за третиране | Цена на пакета от контроли | €74,000 за превключване към резервен ресурс, мониторинг и тестване |
| Остатъчна очаквана годишна загуба | Оценена годишна експозиция след третиране | €62,000 |
| Решение | Третиране, прехвърляне, избягване или приемане | Третиране и преглед на остатъчния риск при преглед от ръководството |
Числата не трябва да са съвършени. Те трябва да бъдат обяснени. Допусканията за въздействие може да включват загуба на приходи, кредити по SLA, компенсации за клиенти, реагиране при инциденти, правни консултации, форензична поддръжка, извънреден труд, клиентска поддръжка, усилия за регулаторно уведомяване, отлив на клиенти и репутационен ефект. Допусканията за честота може да произтичат от вътрешни инциденти, доклади за прекъсвания при доставчици, разузнаване за заплахи, секторен опит, експозиция на уязвимости, одитни констатации и зрялост на контролите.
Zenith Blueprint, фаза „Управление на риска“, стъпка 10, „Определяне на критерии за риск и матрица на въздействието“, обяснява защо моделът трябва да бъде калибриран:
„Когато дефинирате въздействие, е разумно нивата да се свържат с конкретния мащаб на вашия бизнес. Например: „Съществено финансово въздействие = загуба > $100k“ (адаптирайте към вашия контекст). Също така вземете предвид регулаторното въздействие: например нарушение на сигурността на личните данни може автоматично да бъде „съществено“ или „тежко“ поради глоби по GDPR и изисквания за уведомяване, дори ако пряката финансова загуба е неясна.“
Това е мостът между качествения и количествения риск. „Съществен“ става смислено само когато организацията дефинира какво означава съществено във финансов, оперативен, правен и клиентски контекст.
Работен пример: количествено оценяване на риска от прекъсване на облачна услуга на доставчик
Представете си доставчик на SaaS, който обслужва клиенти от финансовия сектор. Той зависи от хостинг доставчик в облак, управлявана платформа за бази данни, платежен шлюз и услуга за уведомяване на клиенти. Екипът избира един сценарий за количествен анализ:
„Продължително прекъсване на управлявана платформа за бази данни причинява прекъсване на клиентска услуга и забавяне на обработката на транзакции.“
Стъпка 1: дефиниране на сценария на риска и собственика
Политиката за управление на риска за МСП изисква описание, вероятност, въздействие, оценка, собственик и план за третиране. Корпоративната Политика за управление на риска, раздел „Изисквания за управление“, клауза 5.2.2, добавя, че регистърът:
„Включва собственици на риска, оценки за въздействие и вероятност, планове за третиране, крайни срокове и препратки към контроли“
Собственикът не е „ИТ“. Отговорният собственик е собственикът на услугата, подпомаган от CISO, CTO, мениджъра по съответствие, мениджъра на доставчици и финансовия екип.
Стъпка 2: оценка на финансовата експозиция
Екипът оценява:
- €35,000 на час загубени приходи от транзакции и кредити по SLA
- €8,000 на час разходи за поддръжка, ескалация и обработване на инциденти
- €60,000 разходи за отстраняване на последици за клиенти и комуникации
- €120,000 потенциален отлив на клиенти или търговско въздействие
- 10 часа като вероятно тежко прекъсване въз основа на историята на доставчика и преглед на архитектурата
Загубата при еднократно събитие е:
10 × (€35,000 + €8,000) + €60,000 + €120,000 = €610,000
Текущата вероятност се оценява на 0.25 годишно. Очакваната годишна загуба е:
€610,000 × 0.25 = €152,500
Предложеният пакет за третиране включва дизайн за много-регионално превключване към резервен ресурс, тествано възстановяване на резервни копия, преглед на SLA с доставчика, синтетичен мониторинг, настолно упражнение и актуализация на план за изход. Разходът за първата година е €82,000, с €34,000 повтарящ се разход.
След третиране остатъчната вероятност се оценява на 0.10 годишно, а остатъчната загуба при еднократно събитие — на €350,000 поради по-бързо възстановяване. Остатъчната ALE е:
€350,000 × 0.10 = €35,000
Намалението на очакваната годишна експозиция през първата година е приблизително €117,500, преди да се отчетат регулаторната устойчивост, доверието на клиентите и договорните ползи.
Стъпка 3: избор на третиране и документиране на обосновката
Третирането на риска не винаги е чисто смекчаване. Политиката за управление на риска за МСП на Clarysec, раздел „Изисквания за прилагане на политиката“, клауза 6.1.3, посочва:
„Прехвърляне: използвайте договори, споразумения за ниво на обслужване или застраховка, за да прехвърлите риска външно.“
За този сценарий организацията избира смесено третиране: намаляване чрез техническа устойчивост, частично прехвърляне чрез SLA и договорни средства за защита и приемане на остатъчния риск с одобрение от ръководството.
Стъпка 4: съпоставяне на третирането с Декларацията за приложимост
Корпоративната Политика за управление на риска, раздел „Съгласуване с Декларацията за приложимост (SoA)“, клауза 6.5.1, посочва:
„Решенията за контроли, произтичащи от процеса за третиране на риска, трябва да бъдат отразени в SoA.“
Тук финансовият модел става готов за одит. Сценарият с прекъсване при доставчик се свързва с контролите от ISO/IEC 27001:2022 Приложение A за доставчици, облачни услуги, непрекъсваемост, инциденти и прекъсвания. Той се свързва също със сигурност на веригата на доставки и непрекъсваемост на дейността по NIS2, ИКТ риск от трети страни и тестване на устойчивостта по DORA, сигурност и оценка на нарушение по GDPR, ако са засегнати лични данни, както и с резултатите по NIST CSF за управление, верига на доставки, реагиране и възстановяване.
Zenith Blueprint, фаза „Управление на риска“, стъпка 13, „Планиране на третирането на риска и Декларация за приложимост“, обяснява проследимостта:
„SoA на практика е свързващ документ: тя свързва вашата оценка/третиране на риска с реалните контроли, които имате. Като я попълните, също проверявате повторно дали не сте пропуснали контроли.“
Силна обосновка в SoA може да гласи: „Приложимо, защото прекъсване на управляваната база данни засяга критична клиентска услуга, ИКТ зависимост от трета страна, договорни задължения към клиенти, ангажименти за непрекъсваемост и потенциална наличност на лични данни. Контролите са избрани, за да намалят количествено оценена годишна експозиция от €152,500 и да подкрепят одобрения от ръководството остатъчен риск.“
Стъпка 5: ескалация въз основа на прагове
Корпоративната Политика за управление на риска, раздел „Изисквания за управление“, клауза 5.6, изисква:
„Матрицата на правомощията по риска трябва ясно да дефинира праговете за ескалация към висшето ръководство или ръководния орган.“
Годишна експозиция от €152,500 може да надвишава локалния управленски толеранс. Риск с по-ниска стойност може все пак да изисква ескалация, ако засяга критична или важна функция, задейства очаквания по DORA, включва лични данни, застрашава ангажименти към клиенти или създава отчетност на ръководния орган по NIS2.
Съпоставяне за кръстосано съответствие: един количествено оценен риск, много задължения
Количествено оценен киберриск не трябва да се копира в пет отделни таблици за съответствие. Той трябва да се превърне в един обект на риск с множество изгледи за съответствие.
| Перспектива на съответствие | Какво трябва да показва количествено оцененият риск | Доказателствен артефакт |
|---|---|---|
| ISO/IEC 27001:2022 | Критерии за риск, собственик, вероятност, последствие, третиране, приемане на остатъчния риск, съпоставяне със SoA и оперативни доказателства | Регистър на риска, план за третиране, SoA, преглед от ръководството, одитни записи |
| NIS2 | Подходящи и пропорционални мерки, одобрение и надзор от ръководния орган, съображения за инциденти и непрекъсваемост, мерки за веригата на доставки | Протоколи на ръководния орган, записи за обучения, одобрения за третиране на риска, работен процес за инциденти |
| DORA | Управление на ИКТ риска, критични или важни функции, ИКТ зависимости от трети страни, тестване, класификация на инцидентите и стратегия за устойчивост | Рамка за ИКТ риск, регистър на информацията, резултати от тестове, класификация на инциденти, план за изход |
| GDPR | Обхват на личните данни, мерки за сигурност, последици при нарушение, отчетност на администратор или обработващ лични данни, контекст на законосъобразно обработване | Връзка с RoPA, DPIA когато е приложимо, оценка на нарушение, доказателства за сигурност |
| NIST CSF 2.0 | Апетит за риск, стандартизирана приоритизация, управление, риск от доставчици, резултати за откриване, реагиране и възстановяване | Текущ и целеви профил, план за действие, POA&M, записи за риска от доставчици |
| COBIT 2019 | Управленски цели, мониторинг на изпълнението, оптимизация на риска, решения за ресурси и уверение | Управленско докладване, показатели за резултатност на контролите, доклади за уверение |
NIS2 Article 21 е особено релевантен, защото включва анализ на риска, политики за сигурност, обработване на инциденти, непрекъсваемост на дейността, резервни копия, аварийно възстановяване, управление при кризи, сигурност на веригата на доставки, сигурна разработка, обработване на уязвимости, оценка на ефективността, киберхигиена, обучение, криптография, сигурност на човешките ресурси, контрол на достъпа, управление на активите и автентикация.
DORA създава сходна дисциплина за финансовите субекти, но със секторно специфичен фокус. Тя изисква вътрешна рамка за управление и контрол на ИКТ риска, като ръководният орган носи крайната отговорност. Очаква се одобрение и надзор на ИКТ политики, роли, стратегия за цифрова оперативна устойчивост, толеранс към ИКТ риск, планове за непрекъсваемост и реагиране, одитни планове, бюджети, обучение, политики за ИКТ трети страни и канали за докладване.
DORA също дава на количествената оценка на риска пряк оперативен тригер: класификация на инциденти. Съществените ИКТ-свързани инциденти трябва да се класифицират чрез критерии като засегнати клиенти, контрагенти и транзакции, продължителност, престой, географски обхват, загуби на данни, засягащи наличност, автентичност, цялостност или поверителност, критичност на засегнатите услуги и икономическо въздействие. Ако моделът на риска вече оценява престой, въздействие върху клиенти, въздействие върху данните и икономическа загуба, той подпомага класификацията на инциденти при реално събитие.
Съпоставката на контролите, която прави отчетността на ръководния орган одитируема
В Zenith Controls Clarysec съпоставя ISO/IEC 27002:2022 контрол 5.4, „Отговорности на ръководството“, като управленски опорен контрол за отчетността по информационна сигурност. Ръководството го третира като превантивен, подкрепящ поверителност, цялостност и наличност, съгласуван с концепцията за киберсигурност „Идентифициране“, с управление като оперативна способност и управление плюс екосистема като области на сигурността.
Това има значение, защото финансовата киберекспозиция принадлежи към управленското вземане на решения. Zenith Controls свързва ISO/IEC 27002:2022 контрол 5.4 с няколко поддържащи контрола:
| Връзка с контрол от ISO/IEC 27002:2022 | Защо е важна за количествено оценения риск |
|---|---|
| 5.2 Роли и отговорности по информационна сигурност | Собствениците на риска, собствениците на контроли и органите за ескалация трябва да бъдат дефинирани |
| 5.1 Политики за информационна сигурност | Решенията за количествено оценен риск трябва да са съгласувани с одобрени ангажименти по политики |
| 5.35 Независим преглед на информационната сигурност | Независимият преглед предоставя на ръководството обективно уверение относно третирането на риска |
| 5.36 Съответствие с политики, правила и стандарти за информационна сигурност | Мониторингът на съответствието показва дали третиранията работят по предназначение |
| 5.8 Информационна сигурност при управление на проекти | Новите продукти и промени трябва рано да включват киберриск и финансова експозиция |
Zenith Controls също съпоставя отговорностите на ръководството с клаузи 5.1, 5.2 и 9.3 на ISO/IEC 27001:2022, свързвайки лидерството, политиката и прегледа от ръководството. Допълнително ги съпоставя с клаузи 6 и 7 на ISO/IEC 27014:2020, които се фокусират върху рамки и процеси за управление за оценяване, насочване, мониторинг и комуникиране на информационната сигурност.
Веригата от доказателства е ясна:
- Ръководството дефинира апетит, толеранс и прагове за ескалация.
- Собствениците на риска количествено оценяват водещите киберрискове.
- Контролите се избират и отразяват в SoA.
- Действията за третиране се изпълняват и наблюдават.
- Независимият преглед и мониторингът на съответствието тестват ефективността.
- Прегледът от ръководството оценява резултатността, инцидентите, резултатите от одити, ресурсите и действията за подобрение.
- Ръководният орган получава финансова експозиция, остатъчен риск и доказателства за отчетност на бизнес език.
Политиката за управление на риска за МСП на Clarysec, раздел „Роли и отговорности“, клауза 4.1.1, подсилва тази управленска роля:
„Определя апетита за риск на организацията и одобрява рамката за управление на риска.“
За МСП това може да бъде управителят (GM) или собственикът. За регулиран финансов субект това може да бъде ръководният орган. Принципът на отчетност е един и същ.
Как одиторите и регулаторите ще тестват вашите числа
Количествената оценка на киберриска няма да бъде одитирана като съвършена актюерска наука. Тя ще бъде одитирана за метод, последователност, проследимост, управление и доказателства.
| Перспектива на одитор или оценител | Какво ще бъде тествано | Какви доказателства ще се очакват |
|---|---|---|
| ISO/IEC 27001:2022 | Clause 6.1.2 оценка на риска, clause 6.1.3 третиране на риска, решения в SoA, одобрение от собственика на риска и clause 9.3 преглед от ръководството | Критерии за риск, регистър, план за третиране, SoA, одобрения, протоколи от преглед от ръководството |
| Компетентен орган по NIS2 | Одобрение и надзор от ръководния орган, мерки по Article 21, пропорционалност, готовност за инциденти и обучение | Материали за ръководния орган, записи за обучения, одобрения на риска, процедури за инциденти, доказателства за непрекъсваемост |
| Надзорен орган по DORA или вътрешен одитор | Рамка за ИКТ риск, толеранс към ИКТ риск, критични или важни функции, тестване, класификация на инциденти и ИКТ риск от трети страни | Регистър на ИКТ риска, стратегия за устойчивост, регистър на информацията, резултати от тестове, планове за изход |
| Оценител по NIST CSF 2.0 | Резултати GOVERN, включително GV.RM-02 апетит и толеранс към риск и GV.RM-06 стандартизирана приоритизация | Текущ профил, целеви профил, план за действие, връзка с корпоративния риск |
| Оценител по COBIT 2019 | Управление на корпоративните ИТ, оптимизация на риска, права за вземане на решения, разпределяне на ресурси и уверение | Управленско докладване, показатели за изпълнение, доклади за уверение |
Политиката за одит и мониторинг на съответствието за МСП на Clarysec Политика за одит и мониторинг на съответствието - МСП, раздел „Изисквания за управление“, клауза 5.4.3, прави одитния цикъл изричен:
„Одитни констатации и актуализации на статуса трябва да бъдат включени в процеса на преглед от ръководството на СУИС.“
Това е критично. Ако моделът на риска оценява експозиция от €500,000, но вътрешен одит установи, че тестът за възстановяване е неуспешен, остатъчният риск трябва да се промени. Ако планът за изход от доставчик не е тестван, организацията не трябва да приема остатъчния риск така, сякаш контролът е зрял. Ако тестването по DORA идентифицира критичен пропуск, тази констатация трябва да захрани третирането, бюджета и прегледа от ръководството.
Zenith Blueprint, фаза „Одит, преглед и подобрение“, стъпка 28, „Преглед от ръководството“, подкрепя това, като препоръчва входни данни за преглед от ръководството като промени във вътрешни и външни въпроси, регулаторни изисквания, резултати от одити, мониторинг и измерване, цели, инциденти, несъответствия, възможности за подобрение и потребности от ресурси. В програма за количествено оценяване на киберриска пакетът за преглед от ръководството трябва да включва водещите финансови експозиции, тенденцията от последния преглед, напредъка по третирането, просрочени действия, остатъчен риск над толеранса и необходимите решения.
Изграждане на пакет за киберриск, готов за ръководния орган
Пакетът за киберриск, готов за ръководния орган, не трябва да удавя директорите в брой уязвимости, променливи по FAIR или идентификатори на контроли. Той трябва да превежда киберриска в решения.
За всеки водещ количествено оценен риск включете:
- Име на сценария и засегната бизнес услуга
- Критичност на услугата или функцията
- Маркери за лични данни, регулирана услуга и зависимост от доставчик
- Текуща оценка на загубата при еднократно събитие
- Текуща оценка на годишната честота на настъпване
- Текуща очаквана годишна загуба
- Допускания и ниво на увереност
- Текущи контроли и известни пропуски
- Варианти за третиране и разход
- Очаквана остатъчна експозиция след третиране
- Релевантност спрямо ISO/IEC 27001:2022, NIS2, DORA и GDPR
- Собственик на риска и необходимо решение
- Препратки към SoA и политики
- Краен срок и дата за преглед
Опростен изглед за ръководния орган може да изглежда така:
| Сценарий на риск | Текуща ALE | Разход за третиране | Остатъчна ALE | Регулаторен фактор | Решение |
|---|---|---|---|---|---|
| Прекъсване на управлявана база данни, засягащо обработката на транзакции | €152,500 | €82,000 | €35,000 | ИКТ риск по DORA, третиране на риска по ISO, непрекъсваемост при доставчик | Одобряване на третирането |
| Ransomware, засягащ платформа с клиентски данни | €372,000 | €100,000 | €95,000 | Риск от нарушение по GDPR, обработване на инциденти по NIS2, контроли за инциденти по ISO | Одобряване на EDR и неизменяеми резервни копия |
| Компрометиране на привилегирован достъп в облачна административна конзола | €260,000 | €58,000 | €72,000 | Контрол на достъпа по ISO, автентикация по NIS2, цялостност на данните по DORA | Одобряване на подобрения в MFA и PAM |
| Риск от концентрация при критичен SaaS доставчик | €190,000 | €45,000 | €95,000 | Риск от трети страни по DORA, верига на доставки по NIS2, контроли за доставчици по ISO | Одобряване на тестване на план за изход |
Числата са оценки, но управленската стойност е реална. Ръководният орган може да сравнява приоритети. CISO може да обоснове разходи. Финансовият екип може да валидира допусканията. Съответствието може да свърже решенията със задълженията. Одиторите могат да проследят доказателствената следа.
Чести грешки при количествено оценяване на киберриска
Първата грешка е фалшивата точност. Модел, който твърди загуба от €487,239.17 без ясни допускания, е по-малко убедителен от диапазон с документирана основа. Използвайте диапазони, когато е подходящо, и преглеждайте допусканията след инциденти, одити, промени при доставчици и съществени архитектурни решения.
Втората грешка е да се отчита само техническият разход. Съществен киберинцидент може да включва загуба на приходи, компенсации за клиенти, оперативно прекъсване, регулаторно докладване, правни консултации, форензична поддръжка, разходи за комуникация, договорни санкции, отлив на клиенти, време на ръководството и репутационен ефект.
Третата грешка е да се пренебрегва регулаторната сериозност. Нарушение на сигурността на личните данни може да бъде съществено дори когато пряката оперативна загуба изглежда умерена. Инцидент по DORA може да бъде значим поради критичност на услугата, престой, загуба на данни или засегнати клиенти. Инцидент по NIS2 може да бъде съществен, защото причинява тежко оперативно прекъсване, финансова загуба или значителна вреда за други лица.
Четвъртата грешка е SoA да не се актуализира. Ако решенията за третиране избират мониторинг на доставчици, планиране на изход от облачни услуги, събиране на доказателства при инциденти, ИКТ готовност за непрекъсваемост на дейността или контроли при прекъсвания, SoA трябва да отразява приложимите контроли и статуса на внедряване.
Петата грешка е финансовият екип да бъде оставен извън процеса. Количествената оценка на киберриска е най-силна, когато сигурността, финансите, правният отдел, операциите, продуктът и съответствието постигнат съгласие по допусканията за въздействие. CISO не трябва сам да измисля числата за загуба на приходи.
Шестата грешка е застраховката да се третира като пълно прехвърляне на риска. Застраховката може да намали финансовото въздействие, но не премахва регулаторната отчетност, прекъсването на услугите, загубата на доверие на клиентите или отговорността на ръководството.
Къде се вписва Clarysec
Clarysec помага на организациите да изградят програма за киберриск, която е достатъчно практична за МСП и достатъчно строга за регулирани среди.
Zenith Blueprint води организацията от обхват и контекст през критерии за риск, качествена и количествена оценка, планиране на третиране, проследимост на SoA, одит, преглед от ръководството и подобрение. Zenith Controls помага очакванията към контролите по ISO/IEC 27001:2022 и ISO/IEC 27002:2022 да се съпоставят с други рамки, одити и управленски задължения. Политиките на Clarysec предоставят езика, който одиторите очакват, включително апетит за риск, матрици на правомощията, варианти за третиране, регистри на съответствието, съгласуване със SoA и интеграция с прегледа от ръководството.
Политиката за правно и регулаторно съответствие за МСП Политика за правно и регулаторно съответствие - МСП, раздел „Изисквания за управление“, клауза 5.1.1, започва с просто задължение:
„GM трябва да поддържа прост, структуриран регистър на съответствието, който изброява:“
Този прост регистър има значение. Правните, регулаторните и договорните задължения трябва да бъдат видими в СУИС. За количествения риск това означава, че NIS2, DORA, GDPR, клиентските договори, SLA, задълженията при възлагане на дейности, задълженията за докладване на инциденти и ангажиментите за одит оформят въздействието, приоритета на третирането и ескалацията.
Корпоративната Политика за управление на риска, раздел „Референтни стандарти и рамки“, клауза 11.9.1, също директно отразява управление в стила на DORA:
„Article 5: изисква документирана рамка за управление на ИКТ риска, напълно покрита от структурата на тази политика, включително съпоставяне със SoA и KRI.“
Това е моделът на Clarysec в едно изречение: документирано управление на ИКТ риска, съпоставено с контроли, измервано чрез индикатори, преглеждано от ръководството и доказуемо при одит.
Следващи стъпки: направете своя регистър на киберриска за 2026 г. финансово защитим
Ако текущият ви регистър на киберриска все още казва „висок“, без да обяснява финансовата експозиция, икономиката на третирането или регулаторното въздействие, започнете с пет действия през това тримесечие:
- Изберете водещите 5 до 10 сценария на киберриск според въздействието върху бизнеса.
- Дефинирайте прагове за финансово въздействие за незначително, умерено, съществено и тежко.
- Оценете загубата при еднократно събитие, годишната честота на настъпване и очакваната годишна загуба за всеки водещ сценарий.
- Съпоставете всяко решение за третиране с контролите по ISO/IEC 27001:2022, SoA, задълженията по NIS2 или DORA, когато е приложимо, последиците по GDPR и резултатите за управление по NIST CSF.
- Представете остатъчния риск, разхода за третиране и праговете за ескалация при преглед от ръководството.
Clarysec може да ви помогне да превърнете това в повторяема система за доказателства чрез Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, корпоративната Политика за управление на риска Политика за управление на риска, Политиката за управление на риска за МСП Политика за управление на риска - МСП и поддържащи шаблони за одит и съответствие.
Целта не е киберрискът да стане напълно предвидим. Целта е той да бъде обясним, съпоставим, финансово значим и одитируем.
Изтеглете шаблоните на Clarysec за политики за риск и съответствие, разгледайте Zenith Blueprint или резервирайте оценка от Clarysec, за да превърнете своя регистър на киберриска за 2026 г. в доказателства, готови за ръководния орган, за ISO/IEC 27001:2022, NIS2, DORA и GDPR.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


