DORA тестване на оперативната устойчивост: член 24

Член 24 е кратък. Шест параграфа. Голяма част от онова, което му се приписва, липсва в него, затова това ръководство цитира текста и след това казва ясно откъде идва останалото.

Програмата за тестване на цифровата оперативна устойчивост се намира в глава IV от Регламент (ЕС) 2022/2554, в членове 24 до 27. Член 24 урежда задължението за програмата, член 25 изброява видовете тестове, а членове 26 и 27 уреждат тестването на проникване, основано на заплахи. DORA се прилага от 17 януари 2025 г.

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

Какво всъщност казва член 24

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

Член 24 е една от по-добре написаните части на DORA: кратък, без лабиринти от препратки и честен за това, че програмата за тестване е въпрос на професионална преценка. Трудността, която създава, е обратната на обичайната. Предписанията са толкова малко, че почти всичко в програмата ви е ваше собствено решение, което трябва да защитите, а решението се доказва по-трудно от контролен списък.

Останалата част от члена, накратко и със собствените му думи:

Забележете какво липсва. Член 24 не споменава ръководния орган. Не определя честоти извън годишния тест по 24(6). Не оправомощава регулаторен технически стандарт. Ако сте виждали позоваване на „RTS по член 24(2)“, такъв не съществува; RTS, който има значение в тази глава, е този за TLPT, изискван от член 26(11).

Наистина ли ръководният орган трябва да одобри програмата за тестване?

Да, макар че основанието е извън член 24, и разграничението има значение, когато някой ви помоли да посочите изречението. Член 24 мълчи по въпроса за ръководния орган. Задължението произтича от две разпоредби, четени заедно:

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

Това е издържана верига и точно така ще я прочетат надзорните органи. Но това е верига от разсъждения и е добре да го знаете предварително, вместо да го откриете при оспорване. Член 5(2) изброява конкретни задължения за одобрение в букви (a) до (i), като програмата за тестване остава извън изрично посочените елементи. Това, което списъкът посочва изрично и което съответно трябва да очаквате да доказвате отделно, включва стратегията за цифрова оперативна устойчивост в буква (d), политиката за непрекъснатост на ИКТ дейността и плановете за реагиране и възстановяване в (e), плана за вътрешен ИКТ одит в (f), бюджета в (g) и политиката за ИКТ услуги от трети страни в (h).

Още две разпоредби си струва да бъдат представени пред самия ръководен орган. Член 5(4) изисква членовете „да поддържат активно достатъчно знания и умения, за да разбират и оценяват ИКТ риска“, включително чрез специално обучение на редовна основа. А член 50(5) предвижда, че държавите членки предоставят на компетентните органи правомощието да прилагат административни санкции и корективни мерки, при спазване на националното право, „спрямо членовете на ръководния орган и спрямо други лица, които съгласно националното право носят отговорност за нарушението“.

Така че личната отговорност е реална, но е реална по конкретния начин, по който регламентът я конструира: чрез националното право, по член 50(5). Тя има точно определено основание и прецизното ѝ описание е по-убедително пред ръководен орган от драматизирането ѝ.

Член 25: списъкът е примерен

Това е най-съществената грешна интерпретация в обращение. Член 25(1) гласи, че програмата „включва ... извършването на подходящи тестове, като например оценки и сканирания за уязвимости, анализи на отворен код, оценки на мрежовата сигурност, анализи на пропуските, прегледи на физическата сигурност, въпросници и софтуерни решения за сканиране, прегледи на изходния код, когато това е осъществимо, тестове по сценарии, тестове за съвместимост, тестове за производителност, тестове от край до край и тестове за проникване“.

„Като например“ въвежда примери. Задължението е да се извършват подходящи тестове, подбрани чрез основания на риска подход, който изисква член 24(3). Това не е контролен списък от десет точки за отмятане. Програма, която механично прилага всяка изброена техника към всяка система без обосновка на риска, вероятно стои по-далеч от член 24(3), отколкото програма, която преценява кое е подходящо и записва обосновката си.

Записването на тази обосновка е бърза работа, следобед за повечето инфраструктури, и е страницата с най-висока стойност в целия програмен документ. Механичното прилагане на всяка техника от списъка към всяка система е година бюджет, похарчен за вид на заетост, и пак ви оставя без единственото нещо, което член 24(3) всъщност изисква.

По-долу е пълният списък по член 25(1), с колона за честота. Честотите са наши и се предлагат като отправна точка. DORA не определя честота за нито един от тях, освен годишното задължение по член 24(6). Ако ги приемете, приемете ги като ваше решение, което няма характер на регулаторно изискване.

Кой попада в обхвата

Тук си струва да сте внимателни, защото изключенията често се предават неточно и не всички са едно и също изключение.

• Задължението за програма по член 24 се прилага за финансови субекти, различни от микропредприятия. Микропредприятията остават извън самото изискване за програма.
• Член 25(3) указва на микропредприятията как да подходят към тестовете по член 25(1): като съчетават основан на риска подход със стратегическо планиране, балансирайки ресурсите и времето спрямо неотложността, вида риск и критичността. Тоест те също подлежат на тестване, но по различен режим.
• Член 16(1) е отново нещо отделно: опростена рамка за управление на ИКТ риска за конкретен затворен списък от субекти, включително малки и невзаимосвързани инвестиционни посредници и някои освободени платежни институции и институции за електронни пари. Това е самостоятелен режим, различен от режима за микропредприятията, а смесването на двете е честа грешка.
• TLPT по член 26(1) изключва както микропредприятията, така и субектите по член 16(1), а след това се прилага само за онези субекти, които компетентен орган е идентифицирал по член 26(8).

Изключението за микропредприятията и опростеният режим по член 16(1) постоянно се смесват, а грешката струва скъпо и в двете посоки: дружества се освобождават от програма, която дължат, или изграждат такава, от която никога не са имали нужда. Внимателният прочит на двете определения решава въпроса на едно сядане.

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

Изграждане на годишната програма

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

1. Обхват

Започнете от критичните или важните функции, защото към тях член 24(6) обвързва годишното задължение. DORA определя критична или важна функция в член 3(22) като функция, чието прекъсване „би влошило съществено финансовите резултати на финансовия субект или надеждността или непрекъснатостта на неговите услуги и дейности“. Всяка ИКТ система и приложение, поддържащи такава функция, попадат в обхвата на поне годишно тестване, включително когато поддържащата услуга се предоставя от трета страна.

2. Календар

Съотнесете всеки избран вид тест към честота и отбележете ясно кои честоти са регулаторни и кои са ваши. Точно една е регулаторна: годишният тест на системите, поддържащи критични или важни функции, по член 24(6). За субектите, идентифицирани по член 26(8), TLPT се провежда най-малко на всеки три години. Всичко останало в календара ви е основан на риска избор, който сте направили и трябва да можете да обосновете по член 24(3).

3. Кой провежда тестовете

Член 24(4) изисква независими тестващи, вътрешни или външни. Когато са вътрешни, трябва да отделите достатъчно ресурси и да избегнете конфликти на интереси както при проектирането, така и при изпълнението на теста. TLPT затяга това значително: по член 27(2) използването на вътрешни тестващи за TLPT изисква компетентният орган да го е одобрил и да е проверил, че разполагате с достатъчно отделени ресурси и управлявани конфликти на интереси, а доставчикът на разузнавателна информация за заплахи трябва да е външен за субекта. Член 26(8) добавя, че субектите, използващи вътрешни тестващи, трябва да наемат външни тестващи на всеки три теста и че кредитните институции, класифицирани като значими, могат да използват само външни тестващи.

4. Приоритизиране

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

5. Констатации

Член 24(5) е параграфът, който най-често се преразказва в нещо, което той не казва. Ето действителния текст: финансовите субекти „установяват процедури и политики за приоритизиране, класифициране и отстраняване на всички проблеми, разкрити при извършването на тестовете, и установяват вътрешни методологии за валидиране, за да установят, че всички идентифицирани слабости, недостатъци или пропуски са изцяло отстранени“.

Две задължения. Приоритизиране, класифициране и отстраняване на проблемите; и валидиране, че те са изцяло отстранени. Второто е онова, което програмите пропускат, и затова затварянето на констатация само въз основа на уверение от инженер е недостатъчно. Нивата на сериозност и сроковете за отстраняване по ниво са разумна практика, но вие ги определяте: DORA не предписва такива.

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

6. Докладване пред ръководния орган

Определете какво достига до ръководния орган и кога. Член 5(2)(i) изисква канали за докладване, които поддържат ръководния орган информиран, наред с другото, поне за големите ИКТ инциденти и тяхното въздействие, както и за мерките за реагиране, възстановяване и корекция. Резултатите от тестовете са естественото допълнение към това. Критичните констатации не бива да чакат тримесечния цикъл.

Колко струва тестването и защо тази статия вече не ви казва

По-ранна версия на тази статия цитираше стойности: 15 000 до 50 000 EUR за външен тест за проникване, 150 000 до 500 000 EUR за TLPT ангажимент, шест до дванадесет месеца изтекло време. Тези числа са премахнати и си струва да се каже защо, вместо да бъдат тихо изтрити.

За тях нямаше източник. DORA не определя стойности. Рамката TIBER-EU на ECB и техническият стандарт за TLPT описват фазите и необходимите роли, но не публикуват разходи. Същото важи и за ESAs. На пазара съществува разпръснат набор от оценки на доставчици и консултанти, които се разминават помежду си няколко пъти, което ви подсказва, че са оферти за различни обхвати и не представляват измерване на нищо. Повтарянето на някоя от тях със знак за евро отпред би облякло догадка във вид на факт, а ръководен орган, който планира бюджет по нея и после открива реалното число, е зле обслужен.

Това, което може да се каже с източник, е по-тясно и по-полезно. Член 5(2)(g) прави бюджета самостоятелно задължение на ръководния орган: ръководният орган трябва „да разпределя и периодично да преразглежда подходящия бюджет за удовлетворяване на нуждите на финансовия субект от цифрова оперативна устойчивост по отношение на всички видове ресурси“, включително програми за повишаване на осведомеността относно ИКТ сигурността и обучения по устойчивост и ИКТ умения за персонала. Тоест ръководният орган е длъжен да финансира устойчивостта адекватно и да преразглежда това финансиране. Колко струва „адекватното“ във вашия случай зависи от обхвата ви, инфраструктурата ви и доставчиците ви, а единственият надежден начин да го разберете е да определите обхвата на ангажимента и да вземете оферти.

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

Факторът за разходите, който се вижда от регламента, е формата на работата. TLPT изисква външен доставчик на разузнавателна информация за заплахи, когато се използват вътрешни тестващи, включва компетентния орган, протича срещу живи производствени системи по член 26(2) и следва фазите в техническия стандарт за TLPT. Това е структурно по-скъпо от сканиране. Не ви трябва измислено число, за да го кажете на ръководен орган.

Управление на програмата във Venvera

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

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

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

DORA е един от няколкото режима, които повечето финансови субекти носят едновременно, а доказателствата от тестването на устойчивостта са сред най-многократно използваемия материал между тях. Двигателят за кръстосано съотнасяне позволява доказателство, произведено веднъж, да обслужи своите съответствия по NIS2 или ISO 27001, вместо да бъде изграждано наново. Специално за страната на TLPT вижте нашето ръководство за тестване на проникване, основано на заплахи, по членове 26 и 27.

Често задавани въпроси

Изисква ли член 24 от DORA ръководният орган да одобри програмата за тестване?

Не с тези думи и член 24 изобщо не споменава ръководния орган. Задължението е реално, но идва през верига от две разпоредби. Член 24(1) прави програмата за тестване „неразделна част от рамката за управление на ИКТ риска, посочена в член 6“, а член 5(2) изисква ръководният орган да определя, одобрява, упражнява надзор и да носи отговорност за прилагането на всички правила, свързани с тази рамка. Одобрението на програмата следва от двете взети заедно. Обърнете внимание, че член 5(2) изброява конкретни задължения за одобрение в букви (a) до (i) и програмата за тестване остава извън изрично посочените елементи, така че всеки, който твърди, че член 24 сам по себе си налага одобрение от ръководния орган, не е чел член 24.

Задължителни ли са всички десет вида тестове в член 25?

Не. Член 25(1) въвежда списъка си с думите „като например“, което му придава примерен характер без изчерпателност или задължителност. Действителното задължение е да се извършват подходящи тестове, избрани чрез основания на риска подход, който изисква член 24(3). Списъкът съдържа и повече от десет елемента, включително анализи на отворен код и „въпросници и софтуерни решения за сканиране“, които редовно отпадат от разпространяваните таблици с „десетте задължителни вида“. Изберете каквото е подходящо за вашия риск и документирайте защо.

Колко често DORA изисква тестове за проникване?

DORA не определя честота за обикновените тестове за проникване. Твърдението, че тест за проникване се изисква на всеки три години, е объркване с тестването на проникване, основано на заплахи, което член 26(1) изисква най-малко на всеки три години и само от субекти, идентифицирани от техния компетентен орган по член 26(8). Честотата, която наистина ви обвързва, е в член 24(6): най-малко веднъж годишно, подходящи тестове на всички ИКТ системи и приложения, поддържащи критични или важни функции. Дали подходящият тест за дадена система е тест за проникване, е основана на риска преценка по член 24(3).

Какво казва DORA за цената на програмата за тестване на устойчивостта?

Нищо. DORA не определя стойности за разходи и нито рамката TIBER-EU на ECB, нито ESAs публикуват такива. Числата, които циркулират за тестове за проникване и TLPT ангажименти, идват от оценки на доставчици и консултанти, които варират в широки граници, защото остойностяват различни обхвати. Това, което регламентът казва, е в член 5(2)(g): ръководният орган трябва да разпределя и периодично да преразглежда подходящия бюджет за удовлетворяване на нуждите на субекта от цифрова оперативна устойчивост по отношение на всички видове ресурси. Бюджетът е задължение на ръководния орган; числото идва от упражнение по определяне на обхвата.

Прилага ли се програмата за тестване за микропредприятия?

Задължението за програма по член 24 се прилага за финансови субекти, различни от микропредприятия, така че микропредприятията стоят извън самото изискване за програма. Те обаче подлежат на тестване: член 25(3) изисква от тях да извършват тестовете, посочени в член 25(1), като съчетават основан на риска подход със стратегическо планиране на ИКТ тестването, балансирайки отделените ресурси и време спрямо неотложността, вида риск и критичността на информационните активи и услуги. Дръжте това отделно от член 16(1), който е съвсем различно изключение и предвижда опростена рамка за управление на ИКТ риска за конкретен затворен списък от субекти.

Какво точно изисква член 24(5) за констатациите?

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

Първични източници

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

• Регламент (ЕС) 2022/2554 (DORA) - членове 3(22), 5, 6, 16, 24, 25, 26, 27 и 50. Съдържа 64 члена и се прилага от 17 януари 2025 г.
• Делегиран регламент (ЕС) 2025/1190 на Комисията - RTS за тестването на проникване, основано на заплахи: критерии, изисквания към тестващите, обхват, фази и методология.
• Делегиран регламент (ЕС) 2024/1774 на Комисията - RTS за инструментите, методите, процесите и политиките за управление на ИКТ риска.
• Рамка TIBER-EU на ECB - рамката за етичен red teaming, основан на разузнавателна информация за заплахи, която стои в основата на TLPT. Не публикува стойности за разходи.

Последна актуализация: юли 2026 г. Обща информация, която няма характер на правен съвет. Честотите на тестване, предложени в тази статия, са примерни стойности по подразбиране на Venvera и нямат характер на регулаторни изисквания; единствената честота, която DORA фиксира в член 24, е годишният тест по член 24(6). Проверявайте позоваванията на членове спрямо действащия текст и насоките на вашия компетентен орган.