DORA в България: какво точно изисква регламентът от банки, платежни институции, инвестиционни посредници, застрахователи и CASP по МиКА през 2026 г.
Alexander Sverdlov
Анализатор по сигурността
Най-важното накратко
- DORA не е директива, а регламент с пряко действие, тоест не чака транспониране в български закон. Прилага се от 17 януари 2025 г. към над 22 категории финансови субекти.
- В България двата компетентни органа са БНБ (банки, платежни и електронни пари, регистър по МиКА за крипто) и КФН (застрахователи, инвестиционни посредници, фондове, пенсионни дружества).
- Регламентът се организира около пет стълба: управление на ИКТ риска, докладване на инциденти, тестване на дигиталната устойчивост (включително TLPT), управление на ИКТ доставчиците (с задължителни клаузи по чл. 30), и оперативен надзор на критичните ИКТ доставчици.
- Срокове за докладване: 4 часа от класификация за първоначално уведомление, 72 часа за междинен доклад, 1 месец за окончателен. Часовникът тръгва от момента, в който инцидентът е класифициран като значителен по RTS критериите.
- Глобите следват националния режим - в България са по Закона за БНБ, Закона за КИО и КЗ. Лична отговорност на ръководството по Търговския закон и секторните закони остава отделен слой над фирмената санкция.
- Реалистична първа година за средно голяма българска платежна институция или инвестиционен посредник: 180 000 - 480 000 лв за пълна готовност, включително регистър на договорни споразумения, политика за управление на ИКТ риска, тест на устойчивостта и доказателствено досие.
През март ни се обади оперативният директор на средно голяма българска платежна институция, лицензирана от БНБ. Беше получил писмо от надзорната служба с искане за регистъра на договорните споразумения по чл. 28 ал. 3 от DORA и за политиката за управление на ИКТ риска по чл. 6. Не разполагаше с нито един от двата документа във вида, който регулаторът очакваше. Имаше политика за информационна сигурност от 2021 г., имаше списък с доставчици в Excel, и имаше две страници с описание на бекъп процедурите.
Срокът беше 21 работни дни. Институцията не е малка - над 80 души, лиценз за платежни услуги по чл. 11 от Закона за платежните услуги и платежните системи, ИКТ инфраструктура хибридна (AWS Frankfurt плюс собствен HSM в Equinix), 14 ИКТ доставчика в общия списък. И никакъв структуриран отговор на това, което DORA нарича управление на ИКТ риска.
Седмица по-късно работехме рамо до рамо с техния CISO и техния правен консултант върху регистъра на договорните споразумения. Това е документът, който БНБ и КФН искат първи, защото показва дали изобщо знаете кои са вашите ИКТ доставчици, какво правят, какви данни докосват, и дали договорите ви съдържат задължителните клаузи по чл. 30 от DORA. Ако не знаете отговора на тези въпроси за всеки от 14-те доставчика, не сте готови за DORA, независимо колко добра е вашата SIEM конфигурация.
Това, което следва, е същият план, по който ги преведохме до готовност за регулаторния отговор. Написано е за директорите по риска, CISO-функции и оперативни директори в български банки, платежни институции, инвестиционни посредници, застрахователи и крипто-доставчици по МиКА, а не за външни консултанти и одитори. До края на материала ще знаете какво точно изисква всеки от петте стълба, кои са най-често пропусканите изисквания, и как изглежда реалистична 90-дневна пътна карта за позиция, която издържа на регулаторен преглед.
Стъпка 1
Какво е DORA и кой в България е в обхвата
DORA (Digital Operational Resilience Act, Регламент (ЕС) 2022/2554 на Европейския парламент и на Съвета) е първият единен европейски режим за дигитална оперативна устойчивост на финансовия сектор. Целта на регламента е да консолидира фрагментираните досега национални правила за киберсигурност и ИКТ риск във финансовия сектор в един общ стандарт, валиден от Лисабон до София. Влязъл в сила на 16 януари 2023 г., регламентът се прилага директно от 17 януари 2025 г., без необходимост от транспониране в български закон.
Обхватът на DORA е широк и засяга над 22 категории финансови субекти. За българския пазар най-важните са следните:
- Кредитни институции (банки) - 18 банки с лиценз в България плюс клонове на ЕС банки. Надзор: БНБ.
- Платежни институции и дружества за електронни пари - около 30 лицензирани субекта. Надзор: БНБ.
- Инвестиционни посредници по ЗПФИ. Надзор: КФН.
- Управляващи дружества и фондове (UCITS, AIF). Надзор: КФН.
- Застрахователи и презастрахователи. Надзор: КФН.
- Пенсионноосигурителни дружества. Надзор: КФН.
- Доставчици на услуги по криптоактиви (CASP) по Регламент МиКА - регистър при БНБ, надзор по координация с ЕЦБ.
- Доставчици на услуги по краудфъндинг (ECSP). Надзор: КФН.
- Централни регистри на ценни книжа, централни контрагенти, борси. Надзор: КФН + БНБ за платежни и сетълмент системи.
Има облекчен режим за микропредприятия (под 10 души и под 2 млн. евро баланс/оборот) - за тях задълженията по чл. 16 са пропорционални. Малки и не взаимосвързани инвестиционни посредници също имат облекчен профил по чл. 16. За всички останали се прилага пълният режим без редукция.
Важна правна особеност, която не всички български субекти осмислят веднага: DORA е lex specialis. В случай на застъпване с други регламенти (NIS2, GDPR, MiCA, PSD2, EBA Guidelines on ICT and security risk management), DORA има приоритет за финансовия сектор. На практика това означава, че финансова институция в България, която вече е изпълнявала задължения по EBA/EIOPA насоки за ИКТ риска, в голяма степен вече покрива DORA, но трябва да обнови документацията си към новата терминология и към допълнителните изисквания, които DORA внася (например регистъра на договорните споразумения и режима за TLPT).
Стъпка 2
Петте стълба на DORA и какво точно изискват
DORA се организира около пет стълба, които заедно покриват целия жизнен цикъл на ИКТ риска във финансова институция. Полезно е да се запомнят като структура, защото и БНБ, и КФН структурират проверките си по същия начин.
Стълб 1. Управление на ИКТ риска (чл. 5-16)
Управителният съвет носи крайна отговорност за ИКТ риска и одобрява рамката му писмено. Назначава се отговорно лице за управление и наблюдение на ИКТ риска (на ниво „контролна функция", разделена от ИТ оперативно лице). Изграждат се: рамка за управление на ИКТ риска, политика за информационна сигурност, идентификация и класификация на активите и функциите, политики за защита (криптография, контрол на достъпа, мрежова сигурност), процедури за откриване (мониторинг 24/7 за критичните функции), процес за реакция и възстановяване, процедури за научени уроци и подобряване, политика за непрекъсваемост и план за възстановяване след бедствие с RTO/RPO. Обучение на персонала и програма за информираност, включително за УС.
Стълб 2. Управление, класификация и докладване на ИКТ инциденти (чл. 17-23)
Процес за откриване, класификация и реакция при ИКТ инциденти. Класификацията използва критериите от Delegated Regulation (EU) 2024/1772 - брой засегнати клиенти, географски обхват, продължителност, финансова загуба, репутационна щета, икономически и социален ефект. Значителните инциденти се докладват към БНБ или КФН по образец и в три етапа: първоначално уведомление в рамките на 4 часа от класификацията (и не по-късно от 24 часа от момента на узнаване), междинен доклад до 72 часа, окончателен доклад до един месец. Регистър на всички инциденти - не само значителните - се поддържа постоянно и подлежи на проверка. Сериозни кибер заплахи без реализиран инцидент също се докладват доброволно по чл. 19 ал. 2.
Стълб 3. Тестване на дигиталната оперативна устойчивост (чл. 24-27)
Годишна програма за тестване, пропорционална на размера и сложността. Минимумът включва: уязвимостни оценки, мрежови тестове, source-code анализ за критични приложения, сценариини тестове, тестове на физическата сигурност, performance тестове, тестване на инструментите за откриване, end-to-end тестове на BCP/DRP. Тестванията се извършват от независими страни (вътрешни могат да са независими, ако функцията е разделена). За „значителни" финансови институции, които отговарят на критериите по чл. 24 ал. 3 (системно значими, важни за единен пазар, със значителни ИКТ зависимости), допълнително се прилага TLPT - Threat-Led Penetration Testing - на всеки 3 години, по методология TIBER-EU, под надзора на БНБ/КФН. БНБ работи по адаптация на TIBER-EU за българския пазар.
Стълб 4. Управление на ИКТ риска от трети страни (чл. 28-30)
Стратегия и политика за ИКТ риск от трети страни, одобрена от УС. Регистър на всички договорни споразумения за ИКТ услуги (чл. 28 ал. 3) в стандартизиран формат, докладван годишно към БНБ/КФН. Прединвестиционна проверка на нови ИКТ доставчици. Задължителни договорни клаузи по чл. 30 за всички споразумения, и засилен набор клаузи (включително exit план, sub-outsourcing ограничения, право на одит на място, право на достъп до помещения и системи, локация на данните) за договори, поддържащи „критични или важни функции". Текущ мониторинг на представянето на доставчика. Стратегия за концентрационен риск.
Стълб 5. Споделяне на информация и оперативен надзор на критичните ИКТ доставчици (чл. 31-44, 45)
ЕС-ниво режим за обявяване на „критични ИКТ доставчици от трета страна" (CTPP), под пряк оперативен надзор на ЕС надзорни органи (Lead Overseer). За българските финансови институции практически смисъл: трябва да знаете кои от вашите доставчици са в риск да бъдат класифицирани като CTPP (cloud провайдъри в първа линия: AWS, Microsoft Azure, Google Cloud, плюс големи SaaS платформи) и да поддържате възможност за миграция (exit план). Чл. 45 насърчава доброволно споделяне на информация за кибер заплахи между финансови субекти - в България ще се случва основно чрез CERT-FS на БНБ и FS-ISAC.
Стъпка 3
Регистърът на договорните споразумения и задължителните клаузи по чл. 30
Регистърът по чл. 28 ал. 3 е документът, който БНБ и КФН искат първи при проверка. Не е счетоводен опис на доставчиците. Той е структуриран файл по образец на Регламент за изпълнение (ЕС) 2024/2956, който трябва да обхваща всеки ИКТ договор - от ентърпрайз cloud до 12-евровия SaaS, който вашият юрист използва за подпис на договори.
Стандартният образец изисква данни за всяко договорно споразумение в около 14 категории и в три нива: финансовият субект (вие), договорното споразумение, и доставчикът. На ниво договор се записват: тип услуга (с конкретен код от списъка), функция, която поддържа, дали поддържа „критична или важна функция", дата на влизане в сила, дата на изтичане, бюджет, локация на данните, sub-outsourcing верига, дата на последна оценка на риска. Първоначалното подаване е до 30 април 2025 г.; следващите - годишно. Подаването става през специален електронен канал на БНБ/КФН.
Клаузите по чл. 30 са вторият документ, с който започва вашата DORA готовност. Те се делят на два пакета: базови клаузи (за всички ИКТ договори) и засилени клаузи (само за договори, поддържащи критични или важни функции). Базовият пакет покрива описание на услугата, локация на данните, разпоредби за защита на данните, гарантирани нива на услуга (SLA), процедури за уведомяване при инцидент, право на терминиране в определени случаи, и достъп до информация при проверка от регулатор. Засиленият пакет добавя пълно право на одит (включително на място), exit стратегия с план за миграция и тест, ограничения на sub-outsourcing на критични функции, изискване за участие на доставчика в тестване на устойчивостта.
| Клауза по чл. 30 | Базови договори | Критични / важни функции |
|---|---|---|
| Точно описание на услугата | Задължително | Задължително + по-детайлно |
| Локация на обработка и съхранение на данните | Задължително | Задължително + изрично одобрение преди промяна |
| SLA с количествени измерители | Задължително | Задължително + санкции при неизпълнение |
| Сътрудничество при инцидент | Задължително | Задължително + срокове за уведомяване |
| Право на одит на финансовия субект | На разстояние | На място + достъп до помещения и системи |
| Достъп на регулатора (БНБ/КФН/Lead Overseer) | Задължително | Задължително + неограничен |
| Sub-outsourcing | Уведомяване | Предварително одобрение + ограничения |
| Exit стратегия и план за миграция | Препоръчително | Задължително + изпитан |
| Участие в TLPT и тестване | Не | Задължително |
| Прекратяване и условия за неговото упражняване | Задължително | Задължително + ясни тригери |
Практически съвет, който спестява много преговори: не започвайте от вашия типов договор. Започнете от стандартизирани шаблони, които EBA, EIOPA и националните браншови асоциации разработиха за DORA. Голяма част от cloud доставчиците (AWS, Microsoft Azure, Google Cloud, Salesforce) вече имат „DORA addendum" - анекс, който поправя стандартния SaaS договор за финансовия сектор. Подписването на този анекс е по-бързо и евтино от пълно предоговаряне.
Стъпка 4
Сроковете за докладване на инциденти и кога точно тръгва часовникът
Сроковете за докладване по DORA са по-кратки и по-точни от това, с което повечето български институции бяха свикнали. Има три отделни доклада, които текат паралелно, и един четвърти срок, който се отнася до значителни кибер заплахи без реализиран инцидент.
Критериите за „значителен" инцидент са изброени в Делегиран регламент (ЕС) 2024/1772 и текат по два прага. Първичен праг: ако инцидентът засяга поне един от показателите - влияние върху критични услуги, репутационна щета, продължителност и downtime, географски обхват, обем на изгубени данни, икономическа загуба - над определени стойности. Втори праг: ако едновременно са изпълнени поне два от показателите засегнати клиенти, репутация, и продължителност и downtime. И двата прага задействат пълния режим на трите доклада.
Една практическа особеност в българския контекст: ако инцидентът има едновременно киберсигурностен и личноданни характер, се задействат паралелно сроковете на DORA (към БНБ или КФН), на NIS2 (към МЕУ-CSIRT, ако сте също в обхвата на ЗКС), и на GDPR (към КЗЛД, 72 часа). Три различни регулатора, три различни срока, три различни доклада. Това трябва да е репетирано на настолно учение, а не да се мисли в реално време в час 3 от инцидента.
Стъпка 5
TLPT, пентест и годишна програма за тестване
Тестването по DORA има два слоя: общо тестване на дигиталната оперативна устойчивост (приложимо за всички финансови субекти, пропорционално на размера и сложността) и Threat-Led Penetration Testing - TLPT - приложимо само за по-голям подмножество, определено от компетентния орган.
Общата програма за тестване по чл. 25 изисква годишен план, който покрива минимум следните области: уязвимостни оценки и сканирания, тестове на мрежовата сигурност, анализ на отворен код за критични приложения, source-code преглед, тестване на физическата сигурност, performance тестове, тестване на инструментите за откриване (SIEM, EDR), end-to-end тестове на BCP и DRP. За критични приложения - годишен пълен пентест. Тестванията се документират, констатациите се възлагат в регистър за отстраняване, а напредъкът се докладва на УС.
TLPT по чл. 26-27 е по-различно нещо. Това е напреднало тестване по сценарии, водено от реална заплахителна разузнавателна информация (threat intelligence), извършвано от външен тийм, при което собствените сини защитници не са предварително уведомени. Методологията следва TIBER-EU (Threat Intelligence-based Ethical Red Teaming framework) на ЕЦБ, която в България се прилага под надзора на БНБ за банките и КФН за капиталовите участници. Първата фаза - подготвителна - отнема около 3-4 месеца, активното тестване около 3 месеца, заключителната фаза с red-team report и remediation план още 2-3 месеца. Цикълът се повтаря веднъж на 3 години.
Кой е длъжен да прави TLPT в България? Не всеки финансов субект. Критериите по чл. 24 ал. 3 и съответната делегирана регламентация (ЕС) 2024/1774 идентифицират финансовите субекти със системно значение, важност за единния пазар, и значителни ИКТ зависимости. Практически за българския пазар това означава: четирите най-големи системно значими банки, основните доставчици на платежни системи (БИСЕРА, БОРИКА), потенциално най-големите застрахователи и инвестиционни посредници. БНБ и КФН ще нотифицират индивидуално кои са в обхвата на TLPT - не се самозаявявате.
Реалистична цена на TLPT за българска банка
Един пълен TIBER-EU цикъл за средно голяма банка струва от 320 000 до 580 000 лв само за външния тийм. Това включва threat intelligence фаза, scoping, изпълнение на сценариите и финална отчетност. Допълнително вътрешно време на CISO функцията, sponsors и WoT (White Team) - около 600-1000 човекочаса. Бюджетирайте това като отделна линия в Year 1 за TLPT финансовите субекти.
Стъпка 6
90-дневна пътна карта до защитима позиция
Ако сте средна по размер българска финансова институция, която все още не е достигнала пълна готовност по DORA, следният 90-дневен план дава защитима позиция за следваща проверка на БНБ или КФН. Не е „пълно съответствие" - няма такова нещо за 90 дни, ако сте започнали от нула - но е позиция, в която регулаторът ще види реален напредък и кохерентна програма.
Реалистична цена за тази 90-дневна работа в средно голяма българска финансова институция (50-150 души, един основен лиценз): 180 000 - 480 000 лв. Разпределение: външен консултант 60-130 хил., правен преглед на договори 25-55 хил., уязвимостна оценка и пентест 20-50 хил., адаптация на политики 10-25 хил., вътрешно време (CISO, юрисконсулт, ИТ, риск мениджмънт, представител на УС) 40-100 хил. лв., обучения 8-25 хил. лв., тестване на BCP/DRP 15-50 хил. лв., софтуер за регистър и доказателствено досие 5-20 хил. лв. първа година. Цените се качват, ако сте в обхвата на TLPT.
Стъпка 7
Петте най-чести грешки в българския финансов сектор
1. „Имаме ISO 27001, значи покриваме DORA"
ISO 27001 покрива по наша оценка около 55-65 на сто от изискванията на DORA. Липсват: регистърът на договорните споразумения по образец, специфичните сроковете за докладване на инциденти, задължителните клаузи по чл. 30, exit стратегиите за критични доставчици, TLPT (където е приложимо), и доказателствата за участие на УС в управлението на ИКТ риска. ISO 27001 е добра основа, но не е DORA.
2. Списък с доставчици в Excel вместо регистър по образец
Регистърът по чл. 28 ал. 3 е структуриран файл в строго определен формат с около 22 задължителни полета на ниво договорно споразумение. Той се подава електронно през канала на БНБ/КФН по образец на Регламент за изпълнение (ЕС) 2024/2956. Excel със 7 колонки „доставчик, услуга, контакт, начало, край, цена, отговорник" не отговаря на изискването, независимо колко актуален е.
3. „Нашият CIO се занимава с ИКТ риска"
DORA изисква контролна функция за управление и наблюдение на ИКТ риска, разделена от оперативната ИТ дейност. CIO-ът, който одобрява архитектурни решения и управлява ИТ персонала, не може едновременно да упражнява контрол върху същите тези решения. Необходим е CISO или ICT Risk Officer, който отчита към УС независимо от CIO. За малки институции тази функция може да се аутсорсва (vCISO), но трябва да е документирана.
4. Игнориране на cloud договорите от чужди вендори
AWS, Microsoft Azure, Google Cloud, Salesforce и големите SaaS вендори имат стандартни DORA анекси за финансовия сектор. Българска институция, която не е поискала и подписала такъв анекс за поддържащ критична функция доставчик, е в нарушение независимо колко добър е базовият договор. Анексът обикновено е безплатен, минималната усилие е поискване и подпис.
5. „24-часовият срок е достатъчен"
Често чуван аргумент: „Имаме общо 24 часа да решим дали инцидентът е значителен и след това още време за уведомление." Грешно. След класификацията тръгва нов часовник от 4 часа до първоначалното уведомление. На практика, ако инцидент бъде засечен в 22:00 ч. в петък и класифициран значителен в 02:00 ч. в събота, първоначалното уведомление трябва да тръгне до 06:00 ч. в събота. Нощни и почивни-дневни дежурства не са препоръка - те са оперативна необходимост.
Как Atlant Security помага
DORA готовност за български финансови институции
Преведохме българска банка, две платежни институции, един инвестиционен посредник и един застраховател през DORA готовност в последните 14 месеца. Знаем какви точно полета търси БНБ в регистъра на договорните споразумения, кой раздел на чл. 30 анекса остава с тежки преговори и кой се подписва за един следобед, и какво очаква CERT-FS на БНБ от формата на първоначалното уведомление.
- Регистър по образеца на Регламент (ЕС) 2024/2956, готов за подаване
- Адаптация на политики и договори с шаблони за български контекст
- vCISO функция, която отговаря на изискването за контролна разделеност
- Тестване и доказателствено досие за следваща проверка
- Реален опит с БНБ и КФН надзорна комуникация
Често задавани
Въпроси на български CISO-функции
Малки сме - 18 души платежна институция. Цялата DORA ли се прилага?
Не. Ако сте микропредприятие (под 10 души и под 2 млн. евро баланс/оборот), задълженията по чл. 16 са в облекчен пропорционален режим. 18-души платежна институция вероятно не е микропредприятие. Но регламентът има клауза за пропорционалност (чл. 4), която позволява опростяване на изискванията в зависимост от размера, профила на риска и сложността. Това не е освобождаване, а адаптация. Адаптацията изисква мотивирано решение на УС и документация.
Дали БНБ вече реално проверява спазването на DORA?
Да. От втората половина на 2025 г. БНБ и КФН включиха DORA готовността като отделна точка в надзорните си цикли. От март 2026 г. виждаме целеви искания за регистъра на договорните споразумения, доказателство за инцидентна класификационна процедура и доказателство за провеждане на годишно тестване. Очаквайте първите формални препоръки за отстраняване по DORA в края на 2026 г., а първите финансови санкции през 2027 г.
Какви глоби могат да се наложат за неспазване на DORA?
DORA не въвежда единна европейска скала за глоби. Санкциите се прилагат по националния режим - в България чрез Закона за БНБ, Закона за кредитните институции, Закона за платежните услуги, Кодекса за застраховането, ЗПФИ, ЗДКИСДПКИ и съответните секторни закони. Размерът зависи от тежестта на нарушението и приложимия секторен закон. Освен фирмената санкция, по Търговския закон членовете на УС могат да носят регресна отговорност при доказана небрежност в управлението.
Аутсорсваме всичко на AWS - те ли носят DORA отговорност?
Не. DORA отговорността остава у вас - финансовия субект - независимо колко много операции сте аутсорснали. Доставчикът трябва да сътрудничи (включително да подпише засилени договорни клаузи и да участва в тестване на устойчивостта), но регулаторно отговорното лице за управлението на ИКТ риска сте вие, заедно с вашия УС. Ако ЕС класифицира AWS като Critical ICT Third-Party Provider (CTPP), той ще получи собствен ЕС надзор, но това не премахва вашите задължения по DORA.
Аз съм CASP по МиКА - DORA приложима ли е към мен?
Да. Регламент МиКА (2023/1114) и DORA (2022/2554) работят в тандем. Всички CASP, лицензирани по МиКА и регистрирани при БНБ, попадат в обхвата на DORA. Има малки изключения за подмножества MiCA участници, но те са тесни. На практика за български CASP това означава: регистър на договорните споразумения (вашият custody доставчик е критичен), политика за управление на ИКТ риска, инцидентни срокове, и засилени договорни клаузи за вашия custody и blockchain infrastructure доставчик.
Аутсорсването на vCISO функция към консултантска фирма приемливо ли е по DORA?
Да, за малки и средни институции е напълно приемливо. Условията: външният vCISO трябва да отчита директно към УС (не през CIO), да има документирано назначение и пълномощно, да е независим от ИТ оперативната функция, и договорът с консултанта трябва да съдържа клаузи за поверителност, продължителност на ангажимента, право на достъп до информация и план за прехвърляне на знание при прекратяване. Не е приемливо vCISO-ът да е същият човек, който прави и оперативната ИТ работа.
Платежната институция, с която започнахме материала, подаде регистъра на договорните споразумения в работния ден преди крайния срок. Получи официално потвърждение от надзорната служба, без бележки. Политиката за управление на ИКТ риска беше одобрена от УС на следващото редовно заседание. Институцията не е „напълно DORA-compliant" - няма такова състояние - но има защитима, документирана и поддържана програма. Това е, което регулаторът търси.
DORA не е еднократен проект. Това е оперативна функция, която трябва да живее. Регистърът се обновява, договорите се преглеждат, инцидентите се класифицират, тестванията се извършват по график, доказателствата се натрупват в досие. Институциите, които третират DORA като проект, го завършват, и после спират, ще се сблъскат с реалността при следващата проверка.
Имате нужда от практическа помощ за DORA готовност в българския финансов сектор? Поискайте 30-минутна консултация или пишете на alexander@atlantsecurity.com.
Александър Свердлов
Основател на Atlant Security. Автор на 2 книги за информационна сигурност, лектор по киберсигурност на най-големите конференции по киберсигурност в Азия и панелист на конференция на ООН. Бивш член на екипа за консултации по сигурността на Microsoft, външен консултант по киберсигурност в Емиратската корпорация за ядрена енергия.