PXLSecurity LTD., София, България Офанзивна сигурност от 2014[email protected]
СъответствиеDORARed Teaming

DORA TLPT или стандартен тест за проникване

От PXLSec26 септември 2026 г.20 мин. четенеОбновено:

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

Две различни задължения

Регламент (ЕС) 2022/2554 — Законът за цифровата оперативна устойчивост, приложим от 17 януари 2025 г. — посвещава Глава IV на тестването на цифровата оперативна устойчивост. Тази глава съдържа две отделни задължения.

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

Второто е тясно и условно. Член 26 изисква усъвършенствано тестване чрез тестване за проникване, водено от заплахи — TLPT — но само от организации, „които са определени в съответствие с параграф 8, трета алинея“. Тази алинея поставя определянето в ръцете на компетентните органи. Организациите по опростената рамка за управление на ИКТ риска по член 16(1) и микропредприятията са изключени направо.

И така: общата програма е нещо, което изграждате, защото DORA се прилага към вас; TLPT е нещо, което извършвате, защото орган ви е казал, че трябва. Повечето попадащи в обхвата организации ще прекарат целия си жизнен цикъл по DORA в първата категория. Малка популация — системно значими банки, най-големите институции за плащания и електронни пари, пазарната инфраструктура, най-големите застрахователи — седи във втората. Само едното от двете е red team.

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

За собствената ни позиция. PXL Security LTD доставя воден от разузнаване red-team тест, съгласуван с подхода TIBER-EU, и подпомага организации, подготвящи се за TLPT. Ние не се представяме за акредитиран или квалифициран доставчик на TLPT по която и да е национална схема, а наемането ни не превръща теста в DORA TLPT. Дали ангажимент се квалифицира и кои изисквания към тестерите се прилагат, се решава от съответния орган.

Какво иска общото задължение за тестване

Член 24 е изискване за програма, не изискване за тест, и иска от вас четири неща.

  • Основана на риска програма, седяща вътре в рамката за управление на ИКТ риска и отчитаща променящия се рисков пейзаж, експозициите на организацията и критичността на нейните активи и услуги. Член 4(2) обвързва Глава IV с размера, рисковия профил и сложността на операциите.
  • Независимост на тестерите. Член 24(4) изисква тестовете да се извършват от независими страни, вътрешни или външни. Вътрешното тестване е позволено, но с достатъчно отделени ресурси и без конфликти на интереси между проектирането и изпълнението. „Независим“ не означава „външен“ — това е структурно свойство, което трябва да докажете.
  • Отстраняване с валидиране. Член 24(5) изисква процедури за приоритизиране, класифициране и отстраняване на всички проблеми, разкрити от тестването, плюс вътрешни методологии за валидиране, потвърждаващи, че всяка слабост, дефицит или пропуск е напълно отстранен. Констатации без затворен цикъл на валидиране не го освобождават.
  • Поне годишно покритие. Член 24(6) изисква организациите да гарантират, поне веднъж годишно, че подходящи тестове се провеждат на всички ИКТ системи и приложения, поддържащи критични или важни функции. Забележете формулировката: подходящи тестове, не един; всички поддържащи системи, не извадка.

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

Къде се вмества обикновеният тест за проникване. Тестването за проникване е един назован инструмент в този списък, а за повечето организации най-информативният. Добре определен по обхват тест на приложение, инфраструктура, облак или платформа за идентичност произвежда доказателство за използваемост на определена повърхност за атака, подредени по критичност констатации за процеса по приоритизиране по член 24(5) и доказателство от повторен тест за валидиране. Онова, което той не е, е заместител на TLPT. Стандартният тест е определен по обхват от инвентар на активите, обикновено обявен, изпълняван със знанието на защитниците и измерван спрямо целеви списък — не дефицити, а точно свойствата, които член 26 премахва.

Какво означава това за вас

  • Третирайте програмата като документиран, преглеждан артефакт, не като календар за доставки.
  • Първо съпоставете критичните или важни функции с поддържащите ги ИКТ системи; не можете да докажете покритие, което не сте съпоставили.
  • Бъдете способни да покажете как работят независимостта на тестерите и избягването на конфликт на интереси, особено ако тествате вътрешно.
  • Включете поправките и вътрешната валидация в програмата. Доказателствата от повторен тест могат да подпомагат процеса по член 24(5), но сами не установяват изпълнение на всички нормативни задължения.
  • Силна програма за тестване за проникване е правилният отговор за повечето попадащи в обхвата организации — и никога не бива да ви бъде продавана като TLPT.

Какво прави един тест „воден от заплахи“

Член 26 и неговите регулаторни технически стандарти — Делегиран регламент (ЕС) 2025/1190 на Комисията, публикуван в Официален вестник на 18 юни 2025 г. — определят TLPT чрез структурни свойства, а не чрез техника. Четири от тях вършат по-голямата част от работата.

  • Воден от разузнаване дизайн на сценарии. Сценариите не се избират от каталог. Външен доставчик на разузнаване за заплахи изгражда профил на заплахата за организацията, идентифицирайки правдоподобни заплашващи субекти и техните тактики, техники и процедури. По РТС контролният екип после избира поне три сценария от този доклад, разграничени по субект и TTP, всеки насочен към критична или важна функция в обхвата; най-много един може да е ориентиран към бъдещето, а не воден от заплаха.
  • Изпълнение спрямо продукционна среда. Член 26(2) е недвусмислен: всеки тест трябва да покрива няколко или всички критични или важни функции на организацията и да се извършва на работещи продукционни системи, поддържащи ги, включително системи зад изнесени функции. Организацията оценява кои функции се нуждаят от покриване, а компетентните органи валидират получения обхват.
  • Надзор от контролен екип и от органа. Организацията назначава контролен екип с назован ръководител, който движи теста, държи знанието за него строго на принципа „необходимост да се знае“, подбира доставчиците и притежава одобрения от управителния орган документ за обхвата. Отделно органът по TLPT движи кибер екип от мениджъри на теста, който участва във всички фази, валидира ключовите артефакти и може да блокира доставчик, когото смята за несъответстващ. Това не е тест, който организацията оценява сама за себе си.
  • Определен процес на приключване. На blue team се казва, че е имало тест; тестерите и защитниците всеки произвеждат доклад; двете страни възпроизвеждат офанзивни и дефанзивни действия; а purple teaming покрива това, което е останало непроверено. Член 26(6) после изисква резюме на констатациите, планове за отстраняване и документация за съответствие да отидат при органа, който по член 26(7) издава атестация — механизмът, позволяващ взаимно признаване между компетентните органи.

TIBER-EU е европейската рамка за ориентир. Член 26(11) насочи ЕНО да разработят РТС „в съответствие с рамката TIBER-EU“, а РТС заявяват, че отразяват методологията, процеса и структурата на тази рамка. TIBER-EU е рамката на Европейската централна банка за етичен red-teaming, базиран на разузнаване за заплахи, актуализирана от Евросистемата през януари 2025 г. за привеждане в съответствие със стандартите на DORA. Тя протича в три фази — подготовка (уведомяване, определяне на обхват, избор и възлагане на доставчици); тестване, разделено между разузнаване за заплахи и после активен red teaming; и затваряне (отчитане, възпроизвеждане, purple teaming, отстраняване, атестация) — а ролите ѝ съответстват на еквивалентите в регламента. РТС също така поставят минимум от дванадесет седмици за активната фаза на red team: двуседмичен ангажимент не е TLPT, както и да е описан.

                   Стандартен тест за              TLPT по DORA чл. 26
                   проникване
---------------------------------------------------------------------------------
Отключвател        Собствената ви програма         Определяне от компетентния
                   за тестване (чл. 24 и 25)        или органа по TLPT

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

Разузнаване        Опит на тестера, публично        Външен доставчик на
                   познание за CVE / TTP            разузнаване; профил на
                                                    заплахата; >= 3 сценария
                                                    по субект

Целева среда       Производствена, стейджинг        Само живи производствени
                   или представителна реплика       системи; без заместване

Надзор             Мениджър на теста от             Контролен екип; обхват,
                   клиента; без регулатор           одобрен от борда; мениджъри
                                                    на теста от органа, всяка фаза

Резултат           Технически доклад, оценки        Доклади на red и blue team,
                   на критичност, доказателство     възпроизвеждане, purple
                   от повторен тест                 teaming, констатации и планове
                                                    до органа, атестация от органа

Кой всъщност е в обхвата

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

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

Потвърдете с компетентния TLPT орган дали вашето дружество трябва да провежда TLPT и как ще бъде третиран предложеният тест. Доброволен red team не е автоматично регулиран TLPT и сам не дава удостоверение от органа. Не извеждайте освобождаване или признаване само от етикета на доставчика.

Член 26(1) определя честотата на поне веднъж на три години и изрично позволява на компетентния орган да я намали или увеличи въз основа на рисковия профил и оперативните обстоятелства на организацията. Надзорът също варира: член 26(9) позволява на държавите членки да определят един национален орган по TLPT, а член 26(10) позволява на компетентен орган да делегира тези задачи на друг национален орган. Вашият контрагент по TLPT може да не е надзорникът, с когото работите всеки ден.

Още една точка има отношение към избора на доставчик. Член 27 изисква тестерите да са с най-висока професионална компетентност и добра репутация, да демонстрират експертиза в разузнаването за заплахи, тестването за проникване и red team тестването, да са сертифицирани от акредитиращ орган в държава членка или да спазват формални кодекси за поведение или етични рамки, плюс независима увереност за стабилно управление на рисковете на TLPT и покритие на професионална отговорност. Контролният екип трябва да оцени кандидат спрямо тези изисквания и да докаже съответствие, преди да сключи договор, и не бива да продължава, когато органът не е съгласен. Няма общоевропейски регистър на одобрени фирми за TLPT, уреждащ това предварително — пригодността се оценява за всеки тест, за всяка организация, от органа, който го надзирава. Повече за това как подхождаме е на нашата страница за DORA и TLPT.

Какво означава това за вас

  • Установете статуса си, преди да планирате бюджет: попитайте компетентния си или национален орган по TLPT дали сте били определени по член 26(8).
  • Ако не сте били определени, инвестирайте в програмата по член 24 и 25. Информиран от заплахи red team пак е силна увереност — просто не го отчитайте като TLPT.
  • Ако сте били определени, планирайте цикъл от поне веднъж на три години, с присъствие на органа във всяка фаза.
  • Оценете пригодността на доставчика спрямо член 27 и РТС сами и очаквайте органът да формира собствено мнение. Третирайте всяко твърдение за предварително одобрена TLPT акредитация със скептицизъм — включително нашето, защото ние не правим такова твърдение.

Как ангажиментите действително се различават

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

Кой знае, че тестът се случва. Стандартен тест за проникване е обявен: SOC знае, управлението на промените има заявка, а екипът за защитната стена вероятно е поставил трафика на тестера в белия списък. Воден от заплахи тест обръща това. Знанието седи при малък контролен екип — по TIBER-EU еквивалентният white team е описан като единствените хора в тестваната организация, които знаят, че се случва. РТС изискват този екип да е възможно най-малък, с информация, споделяна на принципа „необходимост да се знае“, а на служители извън него се казва само когато има убедителни причини и с предварителното съгласие на мениджърите на теста от органа.

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

Как се определя обхватът. За тест за проникване обхватът е търговски разговор: вие казвате какво има значение, ние казваме какво смятаме за липсващо, вие подписвате. За TLPT вие идентифицирате критичните или важни функции и системите и процесите, поддържащи ги — включително доставяните от ИКТ трети страни доставчици на услуги — и подавате документ със спецификация на обхвата, одобрен от управителния ви орган, на органа, който го валидира. РТС също така поставят критериите, които трябва да претеглите, сред тях въздействието на функцията върху финансовата стабилност, значението ѝ за ежедневните операции и нейната взаимосвързаност. Не можете тихо да изключите неудобната система от обхвата: органът вижда разсъжденията ви и валидира контролния ви екип, както и обхвата ви.

Какво означава успех. Тест за проникване успява, когато постигне покритие: тестерът е работил систематично през повърхността за атака, а добрият доклад казва честно докъде не е достигнал. TLPT успява, когато red team преследва определени цели срещу работеща организация, която не знае за теста и активно се защитава, а упражнението доказва дали тази организация е забелязала, колко бързо и какво е направила. Red team, хванат рано, не е провален тест — това е добър резултат, стига откриването да е истинско.

Продължителност и интензивност. Определен по обхват тест на приложение или вътрешна мрежа се изпълнява за дни или седмици. Графикът на TLPT е по-дълъг и до голяма степен фиксиран от регламента. РТС изискват активната фаза на red team тестването да продължи поне дванадесет седмици, като заявената логика е, че по-кратък прозорец не може правдоподобно да имитира скрит заплашващ субект. Това седи вътре в по-дълъг процес: подготовка и доставка, фаза на разузнаване за заплахи, която РТС отбелязват, че обикновено тече около четири седмици според опита с TIBER-EU, тестовият план, после затварянето. Добавете времето за подготовка — документът за обхвата е дължим в рамките на шест месеца от уведомяването на органа — и третирайте цялото нещо като програма, обхващаща по-голямата част от година.

Документите, които получавате. Тест за проникване произвежда един доклад, обикновено с повторен тест. TLPT произвежда документирана верига: документи за иницииране и обхват, целеви доклад за разузнаване за заплахи, тестов план и тестов доклад на red team, доклад на blue team, записът от възпроизвеждане и purple teaming, резюмиращ доклад на теста и план за отстраняване — и накрая атестация, издадена от органа по TLPT, потвърждаваща, че тестът е отговорил на изискванията, и идентифицираща кои функции са били в обхвата. Тази атестация е това, което интересува надзорника ви, и само органът може да я издаде.

Хората и ролите, от които TLPT се нуждае

Замесени са четири страни, а разделението между тях е умишлено, а не бюрократично.

  • Контролният екип, вътре в организацията. Воден от някого достатъчно старши и с достатъчно организационно познание, за да направлява теста, без да разкрива провеждането му, и с достъп до управителния орган. РТС го правят отговорен за комуникациите, за информирането на управителния орган за напредъка и риска, за подбора на доставчика на разузнаване за заплахи и тестерите, за подготовката на документа със спецификация на обхвата и за управлението на риска. Той също предоставя всяка санкционирана помощ на тестерите — договорената помощ (leg-ups), които позволяват на забуксувал сценарий да продължи — и само със съгласието на органа.
  • Отделен доставчик на разузнаване за заплахи. Той събира разузнаване, специфично за вашата организация — реалистичната повърхност за атака, относимите заплашващи субекти и вероятните сценарии — произвеждайки целевия доклад за разузнаване за заплахи, от който се изгражда тестовият план. Където използвате вътрешни тестери, DORA изисква този доставчик да е външен.
  • Red team. Тестерите, които изпълняват сценарии срещу продукционната среда. Член 27 от DORA поставя изисквания към външните тестери, покриващи пригодност и репутация, техническа и оперативна способност, сертификация, независима увереност за стабилно управление на риска от тестването и покритие на професионална отговорност. Вътрешни тестери са позволени само при условия, включително предварително надзорно одобрение, отсъствие на конфликти на интереси и наемане на външни тестери на всеки три теста.
  • Надзорът на органа. Кибер екип за TLPT в рамките на органа, работещ чрез назовани мениджъри на теста, валидира контролния екип и обхвата, бива консултиран за управлението на риска, участва в решенията по време на теста и издава атестацията.

Разделението има значение, защото всяка страна проверява останалите. Разузнаване, произведено от екипа, който ще го използва, се сближава към сценарии, които този екип вече харесва. Организация, която и поставя, и валидира собствения си обхват, с времето ще определя обхвата към това, което може да преживее. И тъй като никоя страна не държи цялата картина, упражнението живее или умира от управлението: одобрения, документирани решения, чиста ескалация, дисциплинирано водене на записи. Ето защо TLPT консумира внимание на риска, правните екипи и борда непропорционално на техническата работа.

Подготовка за воден от заплахи тест

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

  • Идентифицирайте критичните или важни функции, после системите под тях. Не инвентара на приложенията — съпоставянето от бизнес функция към ИКТ системите, процесите и услугите от трети страни, които я поддържат. Организациите многократно намират това съпоставяне остаряло, държано в нечия глава или спиращо на изнесена граница. Поправянето му е месеци работа.
  • Установете контролния екип и неговите пътища за ескалация. Решете предварително кой е буден в 03:00, ако сценарий причини прекъсване, как реален инцидент се различава от тестова дейност, без да се казва на реагиращите, какво задейства спиране и кой може да разреши договорена помощ (leg-up). Запишете го преди тестването, не по време.
  • Уверете се, че откриването и реакцията са наистина неосведомени за теста. По-трудно, отколкото звучи, където ръководството на сигурността е и естественият контролен екип. Ако ръководителят ви на SOC седи в контролния екип, SOC не се тества.
  • Осигурете одобренията от управление на риска и правните екипи рано. Тестването в продукционна среда срещу критични функции се нуждае от документирана оценка на риска, съгласувани мерки за ограничаване на риска, видимост за управителния орган и яснота за договорите, защитата на данните и всяка трета страна, чиято инфраструктура може да бъде докосната.
  • Репетирайте, така че формалният тест да не е първият път, когато организацията ви опитва нещо от това.

Какво означава това за вас

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

Защо репетицията обикновено е правилната първа стъпка

Ако сте изправени пред първи формален тест, определено по обхват противниково упражнение предварително обикновено е добре похарчена инвестиция, по три доста непримамливи причини. То извежда очевидните пропуски евтино: плоски вътрешни мрежи, служебни акаунти с прекомерни права, ненаблюдаван изходящ трафик и данни за достъп в хранилища се намират за дни, а дванадесетседмично регулирано упражнение е скъпо място да ги откриете. То упражнява процеса на контролния екип — първия път, когато организация опита скрито тестване, това, което се чупи, рядко е технологията, а пътят за ескалация, кой какво може да одобри и дисциплината да се пази тайна с месеци. И то променя за какво се харчи формалният тест, защото упражнение, погълнато от основна неправилна конфигурация, дава по-ограничен отговор на въпроса, който има значение: може ли тази организация да открие и реагира на способен противник, преследващ критичните ѝ функции?

Тук red teaming, съгласуван с подхода TIBER-EU, заслужава мястото си като подготовка: същата водена от разузнаване методология и дисциплина на контролния екип, но определени по обхват и време спрямо готовността ви, а не спрямо регулаторен часовник. PXL Security доставя тази работа и подпомага организации, подготвящи се за формално тестване за проникване, водено от заплахи: подкрепа при определяне на обхват, готовност на контролния екип, репетиционни упражнения и отстраняване.

Трябва да сме също толкова ясни за това какво репетицията не е. Тя не е TLPT, не изпълнява задължението и не произвежда атестация. Дали ангажимент се квалифицира и кои тестери могат да го проведат, се определя от вашия орган спрямо DORA и РТС за TLPT — не от който и да е доставчик, и не от нас. PXL Security не се представя за акредитиран или квалифициран доставчик на TLPT по която и да е национална схема, а доставчик, твърдящ друго за собствения си статус, е причина за предпазливост, а не за успокоение.

Чести заблуди

  • „Всяка финансова организация трябва да прави TLPT.“ Не. Общата програма за тестване се прилага широко; TLPT се прилага към организации, определени от компетентните органи спрямо критерии в DORA. Работата в регулиран сектор не ви поставя в обхвата, а допускането, че сте, прахосва бюджет.
  • „Годишният ни тест за проникване го покрива.“ Не го покрива, по структурни причини, а не по причини за качество. Тестът за проникване е обявен, често извън продукционната среда, определен по обхват между вас и доставчика ви и измерван по покритие. Нищо от това не важи за TLPT.
  • „Можем да изпълним red team и да го наречем TLPT.“ Не можете да се самодекларирате. Документът за обхвата и контролният екип се валидират от органа, процесът има определени фази, изискванията към тестерите са поставени в регламент, а атестацията идва от органа.
  • „TLPT заменя останалата част от програмата за тестване.“ То надгражда тази програма. Тест на многогодишен цикъл срещу избрани критични функции не ви казва нищо за приложението, което пуснахте миналия месец.
  • „Резултатът е списък с уязвимости.“ Резултатът е оценка на защитата, откриването и реакцията при реалистична атака, доказана от двете страни: какво направи red team, какво видя blue team и за какво двете се съгласяват, че се е случило при възпроизвеждането. TLPT, прочетен като списък с уязвимости, е прочетен погрешно.

Какво означава това за вас

  • Потвърдете статуса си с органа си, вместо да го извеждате от сектора или размера.
  • Дръжте двете задължения на отделни бюджетни редове; по-широката програма не спира заради TLPT.
  • Съдете за предстоящ тест по това дали може да докаже откриване и реакция, не по дължината на списъка му с констатации.
  • Бъдете скептични към всеки доставчик, твърдящ акредитация, която само орган може да даде.

Вашият компетентен или определен орган по TLPT определя дали TLPT се прилага към вас, процеса, който следвате, кои функции попадат в обхвата и изискванията, на които тестерите трябва да отговарят. Нищо тук не отменя тяхното указание, а позицията се различава между юрисдикциите. Това са практически насоки, базирани на Регламент (ЕС) 2022/2554, РТС за TLPT, издадени по него, и материалите на ЕЦБ за TIBER-EU — не правен съвет.

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

Изпълняваме водени от разузнаване red-team упражнения, съгласувани с подхода TIBER-EU, и ви помагаме да репетирате преди формалния ангажимент.

Обсъдете TLPT ангажимент