Пътна карта DORA 2026 за ИКТ риск, доставчици и TLPT

Паниката около DORA 2026 всъщност не е за регулацията, а за доказателствата

Понеделник е, 08:15 ч., а директорът по информационна сигурност (CISO) на средно голяма платежна институция има отворени три раздела в браузъра: „DORA RTS/ITS checklist“, „DORA ICT third-party register template“ и „TLPT requirements financial entities“.

Мениджърът по съответствие вече е попитал дали пакетът за управителния орган трябва да включва последния работен процес за класификация на инциденти. Екипът по снабдяване иска да въведе нова облачна платформа за анализи. Оперативният директор (COO) иска уверение, че основният доставчик на SaaS за банкови услуги няма скрита експозиция към подизпълнители извън ЕС. Вътрешният одит иска календар за тестване. Правният отдел пита дали сроковете за уведомяване при нарушение по GDPR са съгласувани с докладването на инциденти по DORA.

Никой не задава теоретичен въпрос. Въпросът е: „Можем ли да го докажем до петък?“

Това е реалният проблем на DORA 2026. Повечето финансови субекти разбират основните задължения: управление на ИКТ риска, докладване на инциденти, свързани с ИКТ, тестване на цифровата оперативна устойчивост, управление на риска от трети страни — доставчици на ИКТ услуги, и по-силен надзор върху критичните доставчици на ИКТ услуги. Трудната част е превръщането на Regulatory Technical Standards, Implementing Technical Standards и задълженията на ниво член в контролирана, повторяема и одитируема практика.

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

Проектите по DORA обикновено се провалят по една от три причини. Първо, организацията третира DORA като упражнение по правно съпоставяне, а не като оперативен модел. Второ, рискът, свързан с доставчици, се документира като списък на доставчици, а не като зависимост, заменяемост и риск от концентрация. Трето, тестването се разглежда като ежегоден тест за проникване, а не като програма за устойчивост, която включва сканиране за уязвимости, сценарно тестване, упражнения за инциденти и, когато е приложимо, threat-led penetration testing, често търсено като TLPT.

По-добрият подход е да се изгради единна система от доказателства, която свързва политики, регистри, собственици, рискове, инциденти, доставчици, тестване, възстановяване и преглед от ръководството. Именно тук Zenith Blueprint на Clarysec, готовите за използване политики и Zenith Controls помагат на финансовите субекти да превърнат DORA от краен срок в устойчив оперативен ритъм.

Започнете с оперативния модел по DORA, а не с таблицата RTS/ITS

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

В Zenith Blueprint: 30-стъпкова пътна карта за одитора Clarysec разглежда това във фазата „Управление на риска“, стъпка 14, „Политики за третиране на риска и регулаторни кръстосани препратки“:

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

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

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

За регулираните финансови субекти тази структура превръща внедряването на RTS/ITS в система от доказателства, готова за одит. За субектите с опростено управление на ИКТ риска същият модел може да бъде мащабиран до по-малко документи и по-прости регистри. Основните дисциплини остават същите: идентифициране, защита, откриване, реагиране, възстановяване, тестване и управление на доставчици.

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

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

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

Политиката за управление на риска за МСП на Clarysec предоставя на по-малките финансови субекти кратка доказателствена основа:

„Всеки запис за риск трябва да включва: описание, вероятност, въздействие, оценка, собственик и план за третиране.“
От раздел „Изисквания за управление“, клауза на политиката 5.1.2.

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

„Трябва да се поддържа формален процес на управление на риска в съответствие с ISO/IEC 27005 и ISO 31000, обхващащ идентифициране, анализ, оценяване, третиране, наблюдение и комуникация на риска.“
От раздел „Изисквания за управление“, клауза на политиката 5.1.

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

Силен регистър на ИКТ риска по DORA трябва да включва следните полета:

Практическо упражнение е да се вземе една критична ИКТ услуга, например платформа за мониторинг на трансакции, хоствана в облак, и за 20 минути да се създаде запис за риск. Опишете сценария за отказ или компрометиране, оценете вероятността и въздействието, назначете собственик, идентифицирайте свързаните доставчици, определете план за третиране и свържете записа с доказателства като надлежна проверка на доставчик, SLA, клаузи за инциденти, BIA, резултати от DR тестове, табла за мониторинг и прегледи на правата за достъп.

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

Готовност за RTS/ITS: съпоставяйте задълженията с политики, не с обещания

Практическият смисъл на търсенето „DORA RTS/ITS checklist“ обикновено е „Какви документи ще очакват надзорните органи?“ Финансовите субекти следва да избягват обещания за съответствие чрез общи декларации. Те се нуждаят от съпоставка, която обвързва всяко задължение с политика, контрол, собственик и доказателствен елемент.

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

„Управителят трябва да поддържа прост, структуриран регистър на съответствието, в който се посочват:“
От раздел „Изисквания за управление“, клауза на политиката 5.1.1.

За DORA 2026 вашият регистър на съответствието трябва да включва:

• Задължение по DORA или област на изискване RTS/ITS.
• Приложимост, включително обосновка на пропорционалността.
• Препратка към политика или процедура.
• Собственик на контрол.
• Местоположение на доказателствата.
• Честота на преглед.
• Отворени пропуски и срок за отстраняване.
• Статус на докладване към управителния орган или ръководството.

Това е в съответствие с подхода на Zenith Blueprint, стъпка 14: регулаторните изисквания се съпоставят с контролите и политиките на СУИС, така че нищо да не остава извън обхвата. Вместо да пита „Съответстваме ли на DORA?“, ръководството може да попита „Кои доказателствени елементи по DORA са просрочени, кои критични доставчици нямат планове за изход и кои дейности по тестване още не са довели до доказателства за отстраняване?“

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

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

Точно този въпрос държи много CISO будни. Една организация може да разчита на един голям доставчик на облачни услуги за обработка на трансакции, анализ на данни, клиентски портали и вътрешно сътрудничество. Ако този доставчик претърпи продължителен отказ, регулаторен спор или отказ на подизпълнител, въпросът не е само „Имаме ли договор?“ Въпросът е „Можем ли да продължим критичните услуги, да комуникираме с клиентите и да докажем, че сме разбирали зависимостта преди тя да се прояви като отказ?“

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

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

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

„Регистър на зависимостите от доставчици: функцията за управление на доставчици (VMO) трябва да поддържа актуален регистър на всички критични доставчици, включително данни като предоставяни услуги/продукти; дали доставчикът е единствен източник; налични алтернативни доставчици или възможност за замяна; текущи договорни условия; и оценка на въздействието, ако доставчикът откаже или бъде компрометиран. Регистърът трябва ясно да идентифицира доставчици с висока степен на зависимост (напр. такива, за които няма бърза алтернатива).“
От раздел „Изисквания за внедряване“, клауза на политиката 6.1.

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

Zenith Blueprint, във фазата „Контролите в действие“, стъпка 23, „Организационни контроли“, предоставя практически работен процес за надзор върху доставчици. Той препоръчва съставяне на пълен списък на доставчиците, класифициране на доставчиците въз основа на достъп до системи, данни или оперативен контрол, проверка дали очакванията за сигурност са включени в договорите, управление на риска от подизпълнители и последващи доставчици по веригата, дефиниране на процедури за промени и мониторинг и създаване на процес за оценка на облачни услуги.

В Zenith Controls: Ръководство за кръстосано съответствие контрол 5.21 на ISO/IEC 27002:2022, „Управление на информационната сигурност във веригата на ИКТ доставки“, е съпоставен като превантивен контрол, който поддържа поверителност, цялостност и наличност. Той е свързан със сигурността на взаимоотношенията с доставчици и функцията Identify в киберсигурността. Контролът се свързва със сигурно инженерство, сигурно програмиране, контрол на достъпа, тестване на сигурността, събиране на доказателства, жизнен цикъл на сигурна разработка и външна разработка.

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

От гледна точка на кръстосаното съответствие Zenith Controls съпоставя сигурността на ИКТ веригата на доставки с GDPR Articles 28 and 32, тъй като обработващите и подизпълнителите по обработване трябва да бъдат избирани и надзиравани с подходящи технически и организационни мерки. Това подкрепя очакванията на NIS2 за сигурност на веригата на доставки, включително Article 21 мерки за управление на риска за киберсигурността и Article 22 координирани оценки на риска във веригата на доставки. Съпоставянето е силно и с DORA Articles 28, 29 and 30, където ИКТ рискът от трети страни, рискът от концентрация, подизпълнението и договорните разпоредби са централни.

Подкрепящите стандарти усилват доказателствата. ISO/IEC 27036-3:2021 подкрепя ИКТ снабдяването и сигурността при избор на доставчици. ISO/IEC 20243:2018 подкрепя целостта на надеждните технологични продукти и сигурността на веригата на доставки. ISO/IEC 27001:2022 свързва това с третиране на риска и контролите за доставчици в Annex A.

Докладване на инциденти: изградете веригата за ескалация преди инцидента

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

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

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

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

„Ако инцидент доведе до потвърдено или вероятно разкриване на лични данни или други регулирани данни, правният отдел и DPO трябва да оценят приложимостта на:“
От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.4.1.

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

Zenith Blueprint, във фазата „Контролите в действие“, стъпка 16, „Контроли, свързани с хората II“, поставя акцент върху докладването на инциденти, задвижвано от персонала. Служители, изпълнители и заинтересовани страни трябва да знаят как да разпознават и докладват потенциални инциденти по сигурността чрез прости канали като отделна пощенска кутия, портал или гореща линия. Blueprint свързва това с GDPR Article 33, NIS2 Article 23 и DORA Article 17, защото регулаторното докладване започва с вътрешна осведоменост и ескалация.

В Zenith Controls контрол 5.24 на ISO/IEC 27002:2022, „Планиране и подготовка за управление на инциденти по информационна сигурност“, е съпоставен като коригиращ контрол, който поддържа поверителност, цялостност и наличност, съгласуван с Respond and Recover. Той е пряко свързан с оценка на събития, извличане на поуки от инциденти, регистриране и мониторинг, сигурност по време на прекъсване, непрекъсваемост на информационната сигурност и контакт с органи. Ръководството го съпоставя с DORA Articles 17 to 23 за управление, класификация и докладване на инциденти, свързани с ИКТ, и доброволно уведомяване за киберзаплахи, GDPR Articles 33 and 34 за уведомяване при нарушение и NIS2 Article 23 за уведомяване при инцидент.

Готовият за DORA процес за инциденти трябва да включва:

• Ясни канали за приемане на инциденти.
• Триаж на събития и критерии за класификация.
• Работен процес за ескалация на съществен инцидент, свързан с ИКТ.
• Точки за решение от правния отдел, DPO и за регулаторно уведомяване.
• Тригери за уведомяване при инцидент, свързан с доставчик.
• Изисквания за запазване на доказателства.
• Правила за комуникация с изпълнителното ръководство и управителния орган.
• Преглед след инцидент и извлечени поуки.
• Връзка с актуализации на регистъра на риска и отстраняване на пропуски в контролите.

Подкрепящите стандарти добавят структура. ISO/IEC 27035-1:2023 предоставя принципи за планиране и подготовка при управление на инциденти. ISO/IEC 27035-2:2023 описва стъпките за обработване на инциденти. ISO/IEC 22320:2018 подкрепя командването, контрола и структурираната кризисна комуникация. Това има значение, когато ИКТ прекъсване се превърне в криза с въздействие върху клиентите и субектът трябва да покаже, че решенията са били навременни, координирани и основани на доказателства.

Тестване на цифровата оперативна устойчивост и TLPT: не позволявайте тестът да се превърне в инцидент

Тестването е една от най-търсените теми по DORA 2026, защото е едновременно техническа и силно управленска. Финансовите субекти трябва да тестват ИКТ системи, контроли и процеси. За определени субекти усъвършенстваното тестване като TLPT става централно изискване по DORA Article 26.

Одиторският въпрос не е само „Тествахте ли?“ Въпросът е „Беше ли тестът риск-базиран, одобрен, безопасен, независим, когато се изисква, с изпълнени коригиращи действия и свързан с целите за устойчивост?“

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

„Видове тестове: Програмата за тестване на сигурността трябва да включва най-малко: (а) сканиране за уязвимости, състоящо се от автоматизирани седмични или месечни сканирания на мрежи и приложения за идентифициране на известни уязвимости; (б) тестове за проникване, състоящи се от ръчно задълбочено тестване на конкретни системи или приложения от квалифицирани тестери за идентифициране на сложни слабости; и (в) упражнения на червен екип, състоящи се от сценарно базирани симулации на реални атаки, включително социално инженерство и други тактики, за тестване на способностите на организацията за откриване и реагиране като цяло.“
От раздел „Изисквания за внедряване“, клауза на политиката 6.1.

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

Zenith Blueprint, във фазата „Контролите в действие“, стъпка 21, разглежда защитата на информационните системи по време на одит и тестване. Той предупреждава, че одитите, тестовете за проникване, форензичните прегледи и оперативните оценки могат да внесат риск, защото може да включват повишен достъп, инвазивни инструменти или временни промени в поведението на системата. Blueprint съпоставя този въпрос с GDPR Article 32, очакванията на DORA за тестване на цифровата оперативна устойчивост, съображенията на NIS2 за непрекъсваемост и практиките на COBIT 2019 за безопасно изпълнение на одити и оценки.

В Zenith Controls контрол 5.35 на ISO/IEC 27002:2022, „Независим преглед на информационната сигурност“, е съпоставен като превантивен и коригиращ контрол, който поддържа поверителност, цялостност и наличност. Той се свързва със спазване на политиките, отговорности на ръководството, извличане на поуки от инциденти, защита на записите, изтриване на информация, регистриране и мониторинг. За DORA релевантните задължения за тестване са основно Articles 24 to 27, включително Article 26 за TLPT. Това подкрепя и GDPR Article 32(1)(d), който изисква редовно тестване и оценяване на технически и организационни мерки, както и NIS2 Article 21, който изисква мерки за управление на риска за киберсигурността.

Пакетът за готовност за TLPT по DORA трябва да включва:

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

Непрекъсваемост на дейността и аварийно възстановяване: устойчивостта трябва да бъде оперативна

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

Политиката за непрекъсваемост на дейността и аварийно възстановяване за МСП на Clarysec задава ясна базова линия:

„Организацията трябва да тества както своя BCP, така и своите DR способности най-малко веднъж годишно. Тестовете трябва да включват:“
От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.4.1.

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

„Анализ на въздействието върху бизнеса (BIA) трябва да се извършва най-малко веднъж годишно за всички критични бизнес звена и да се преглежда при значими промени в системи, процеси или зависимости. Резултатите от BIA трябва да определят:“
От раздел „Изисквания за управление“, клауза на политиката 5.2.

За DORA BIA следва да бъде свързан с ИКТ активи, доставчици, реагиране при инциденти и тестване. Ако BIA идентифицира „клиентски плащания“ като критична функция, регистърът на зависимостите от доставчици трябва да идентифицира обработващите, облачните услуги и мрежовите доставчици, които я поддържат. Регистърът на риска трябва да включва сценарии за отказ. Планът за тестване трябва да включва валидиране на устойчивостта. Планът за реагиране при инциденти трябва да включва ескалация и комуникация. DR тестът трябва да създаде доказателства, а не само протокол от среща.

Тази проследимост превръща съответствието с DORA в система за оперативна устойчивост.

Кръстосано съответствие: един набор от доказателства, много одиторски въпроси

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

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

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

Одиторска перспектива: как оценителите ще тестват вашите доказателства по DORA

Готовността по DORA става реална, когато някой поиска доказателства. Различните одитори и оценители ще подходят към една и съща тема от различни ъгли.

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

Одиторската перспектива на ISO/IEC 19011:2018 се фокусира върху изпълнението на одита. В Zenith Controls методологията за одит на сигурността на ИКТ веригата на доставки отбелязва, че одиторите проверяват политики за снабдяване, шаблони за RFP и процеси за управление на доставчици, за да потвърдят, че специфичните за ИКТ изисквания за сигурност са вградени от придобиването до унищожаването. За управление на инциденти одиторите проверяват плана за реагиране при инциденти за пълнота и съответствие с най-добри практики. За независим преглед одиторите търсят доказателства, че са проведени независими одити или прегледи.

Перспективата на ISO/IEC 27007:2020 е по-специфична за одит на СУИС. Zenith Controls отбелязва, че одиторите могат да интервюират служители по снабдяване, персонал по ИТ сигурност и мениджъри на доставчици, за да оценят разбирането и изпълнението на контролите във веригата на ИКТ доставки. За подготовка за инциденти те потвърждават, че съществува екип за реагиране при инциденти и че той е оперативен. За независим преглед те проверяват дали програмата за вътрешен одит обхваща пълния обхват на СУИС и е адекватно ресурсно обезпечена.

Оценител, информиран от NIST SP 800-115, ще се фокусира върху методологията за анализ на уязвимости и тестове за проникване. Той може да провери дали обхватът на теста, правилата за изпълнение, констатациите, оценките на тежестта, отстраняването и повторното тестване са документирани. За DORA TLPT това означава, че оценителят няма да се задоволи с набор от слайдове от упражнение на червен екип. Той ще иска доказателство за управление, безопасност, техническа дълбочина и приключване.

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

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

Използвайте този контролен списък като работна базова линия за превръщане на търсенията по DORA в действия.

Управление и съпоставяне с RTS/ITS

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

Управление на ИКТ риска

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

Надзор върху ИКТ трети страни

• Поддържайте регистър на доставчиците и регистър на зависимостите от доставчици.
• Идентифицирайте доставчиците, които поддържат критични или важни функции.
• Оценявайте доставчици, които са единствен източник, и възможността за замяна.
• Преглеждайте подизпълнители и договорености за подизпълнение.
• Включвайте в договорите клаузи за сигурност, достъп, докладване на инциденти, одит и изход.
• Наблюдавайте критичните доставчици най-малко веднъж годишно или след съществени промени.
• Поддържайте планове за изход и извънредни ситуации за доставчици с висока степен на зависимост.

Управление и докладване на инциденти

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

Тестване, упражнения на червен екип и TLPT

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

Непрекъсваемост и възстановяване

• Извършвайте годишен BIA за критичните бизнес звена и го актуализирайте след значими промени.
• Дефинирайте цели за възстановяване на критични функции и поддържащи ИКТ услуги.
• Тествайте способностите за BCP и DR най-малко веднъж годишно.
• Включвайте сценарии за отказ на доставчик и киберинцидент.
• Съхранявайте доказателства от тестове, пропуски, действия за отстраняване и резултати от повторни тестове.
• Съгласувайте плановете за непрекъсваемост с реагирането при инциденти и кризисните комуникации.

Как Clarysec помага на финансовите субекти да преминат от резултати от търсене към доказателства, готови за одит

Готовността по DORA 2026 не се постига чрез изтегляне на контролен списък и надежда, че организацията ще попълни пропуските по-късно. Тя изисква структуриран оперативен модел, който свързва риск, доставчици, инциденти, тестване, непрекъсваемост и одиторски доказателства.

Подходът на Clarysec комбинира три слоя.

Първо, Zenith Blueprint предоставя пътната карта за внедряване. Стъпка 14 помага на организациите да правят кръстосани препратки между регулаторните изисквания, третирането на риска и политиките. Стъпка 16 укрепва докладването на инциденти, задвижвано от персонала. Стъпка 21 гарантира, че одитите и тестовете не застрашават продукционните системи. Стъпка 23 превръща надзора върху доставчици в практически работен процес, който обхваща класификация, договори, подизпълнители, мониторинг и оценка на облачни услуги.

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

Трето, Zenith Controls предоставя картата за кръстосано съответствие. Тя показва как сигурността на ИКТ веригата на доставки, планирането на управление на инциденти и независимият преглед се свързват с DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 и практиките за тестване на NIST.

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

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

Ако екипът ви все още търси „DORA RTS/ITS checklist“, „DORA ICT risk management template“, „DORA third-party oversight“ или „DORA TLPT requirements“, следващата стъпка е да превърнете тези търсения в контролирани доказателства.

Започнете с четири действия тази седмица:

1. Създайте или актуализирайте своя регистър на съответствието по DORA, като използвате модела на политиките на Clarysec.
2. Изберете една критична функция и я проследете през регистъра на риска, регистъра на зависимостите от доставчици, работния процес за инциденти, BIA и плана за тестване.
3. Прегледайте петте си най-значими ИКТ доставчици за възможност за замяна, подизпълнители, клаузи за инциденти и опции за изход.
4. Изградете пакет доказателства за тестване с обхват, оторизация, резултати, коригиращи действия и повторно тестване.

Clarysec може да ви помогне да внедрите това чрез Zenith Blueprint, шаблони за политики и Zenith Controls, така че вашата програма DORA 2026 да бъде практична, пропорционална и готова за одит.