Научете
Един gap анализ е полезен само ако ви казва две неща: колко далеч сте от това, което регулацията действително изисква, и какво да поправите първо. Това ръководство ви дава модел и за двете, като всяка област е закотвена към члена, от който произтича.
Регламентът за цифрова оперативна устойчивост, Regulation (EU) 2022/2554, се прилага от 17 януари 2025 г. Той не предписва метод за gap анализ, скала на зрелост или схема за оценяване. Тези избори са ваши. Това, което предписва прецизно, е съдържанието, спрямо което оценявате, и това съдържание е разпределено в седем области на регламента и три технически стандарта.
Затова тази статия разделя две неща, които обикновено се смесват. Моделът е наш: четиристепенна скала в седем области, след което претеглена. Отбелязваме го като редакционен навсякъде, където се появява. Изискванията, които той измерва, не са наши, и всеки номер на член, срок и брой по-долу е цитиран от регламента или от технически стандарт и е посочен в източниците накрая.
| Приложимо право | Regulation (EU) 2022/2554 (DORA). Прилага се от 17 януари 2025 г. Съдържа 64 члена. |
| Кой попада в обхвата | Финансовите субекти, изброени в Article 2(1). Някои задължения, включително програмата за тестване по Article 24, се прилагат за финансови субекти, различни от микропредприятията. |
| Подробни правила | Commission Delegated Regulation (EU) 2024/1774 (управление на риска, свързан с ИКТ), Commission Delegated Regulation (EU) 2025/301 (съдържание и срокове за докладване на инциденти) и Commission Implementing Regulation (EU) 2024/2956 (регистър на информацията). |
| Изисква ли DORA gap анализ? | Не с тези думи. Article 6(5) изисква рамката за управление на риска, свързан с ИКТ, да бъде документирана и преразглеждана поне веднъж годишно, а също и при големи инциденти, свързани с ИКТ, и след надзорни указания или заключения от тестване или одит. Gap анализът е начинът, по който повечето субекти извършват този преглед. |
| Предписан ли е моделът за оценяване по-долу? | Не. Скалата от 1 до 4, разделянето на седем области и теглата са наши. Използвайте ги или ги заменете. |
Къде gap анализите обикновено се провалят
Смесват наличието с достатъчността. Въпросът "имате ли рамка за управление на риска, свързан с ИКТ?" и отговорът "да" не ви казват нищо за това дали тя отговаря на DORA. Рамка, написана за по-ранен режим на възлагане на дейности, може да не съдържа нищо за риска от концентрация на ИКТ по Article 29, за стратегиите за излизане по Article 28(8) или за стратегията за цифрова оперативна устойчивост, изисквана от Article 6(8). Оценяването по наличие произвежда фалшиво спокойствие.
Оценяват слоя на политиките и пропускат оперативния резултат. DORA има резултати, които или съществуват, или не: регистър на информацията, който трябва да премине валидиране във формата, зададен от ITS, и доклад за инцидент, който трябва да напусне сградата в рамките на фиксиран брой часове. Оценка, която чете само политики, няма да ви каже дали можете да произведете което и да е от двете.
Произвеждат списък. Капацитетът за отстраняване е ограничен, а списък с пропуски без йерархия на спешността е труден за изпълнение. Затова моделът по-долу претегля областите, преди да планира каквото и да е.
Два различни въпроса. Съпоставянето на вашите контроли с библиотека от контроли и измерването на внедряването ви дава поглед върху готовността за одит. Това си струва да го имате, но то не ви казва дали можете да подадете валиден регистър на информацията или да спазите часовника за докладване. Тези две измерения се провалят независимо едно от друго, затова ги оценявайте поотделно. Висок процент на внедрени контроли не казва нищо за това дали едно подаване ще премине валидиране.
Скалата на зрелост
Четири нива, което е достатъчно, за да се разделят смислено различни състояния, без да се измисля прецизност, която доказателствата не могат да поддържат. Да бъдем изрични: тази скала е наша. DORA не дефинира нива на зрелост. Това, което прави една оценка защитима, е че ниво 3 е закотвено към поименно посочен член и че можете да представите доказателствата за него.
| Оценка | Ниво | Определение |
| 1 | Начално | Няма структуриран подход. Изискването е непознато, незапочнато или се обработва ad hoc без документация, отговорник или повторяемост. Отстраняването означава изграждане от нулата. |
| 2 | Развиващо се | Нещо съществува, но не покрива изискването в пълнота. Покритието е частично, документацията е тънка или подходът никога не е бил изпробван. |
| 3 | Дефинирано | Изискването е изпълнено така, както е написано, документирано и поддържано, и можете да представите доказателствата при поискване. Това е базовото ниво, като по-висока зрелост тепърва предстои. |
| 4 | Вградено | Изпълнено, изпробвано или одитирано, с доказателства за ефективност и работещ цикъл на подобрение. Article 6(6) вече подлага рамката на вътрешен одит; оценка 4 означава, че този одит я е намерил за работеща. |
Седемте области, оценени
Всяка област посочва членовете, спрямо които се измерва, след което дефинира какво означава всяка оценка. Всяка цифра, цитирана по-долу, независимо дали е срок, брой или честота, идва от регламента или от технически стандарт. Преди да започнете, имайте предвид, че седемте области далеч не са равни по усилие. D6 е един следобед и по-голямата част от този следобед е записване на решение. D1 и D7 са работа по изготвяне на документи и протоколи, която контролирате от край до край. D2, D4 и D5 са тези, които изяждат месеци, защото и трите зависят от хора извън вашия екип, които да ви отговорят: доставчици, юристи и този, който отговаря за дежурствата извън работно време.
D1. Рамка за управление на риска, свързан с ИКТ
Articles 5 to 15
Article 6(1) изисква стабилна, всеобхватна и добре документирана рамка за управление на риска, свързан с ИКТ. Article 6(5) изисква тя да бъде документирана и преразглеждана поне веднъж годишно, а също и при големи инциденти, свързани с ИКТ, и след надзорни указания или заключения, произтичащи от тестване или одит. Article 6(6) я подлага на вътрешен одит. Article 6(8) изисква тя да включва стратегия за цифрова оперативна устойчивост, а Article 5(2)(d) възлага одобряването на тази стратегия, включително нивото на толерантност към риска, свързан с ИКТ, на ръководния орган.
| Оценка | Как изглежда това |
| 1 | Никаква рамка не е била оценена спрямо DORA. Рамка, изградена за друг режим, никога не е била сравнявана с Articles 5 to 15. |
| 2 | Съществува рамка със съществени пропуски спрямо текста. Обикновено: липсва стратегия за цифрова оперативна устойчивост по Article 6(8), липсва документирано ниво на толерантност към риска, свързан с ИКТ, или липсват доказателства за годишния преглед, който изисква Article 6(5). |
| 3 | Документирана рамка, покриваща Articles 5 to 15, включително стратегията по Article 6(8) и дефинирано ниво на толерантност към риска, с доказан годишен преглед и протоколирано одобрение от ръководния орган. |
| 4 | Рамката е преминала през вътрешен одит по Article 6(6), процесът за проследяване по Article 6(7) за отстраняване на критични одитни констатации, свързани с ИКТ, работи, а подобренията се проследяват до извлечените поуки. |
Най-често недоразвито: стратегията за цифрова оперативна устойчивост по Article 6(8) като отделен одобрен документ, вместо като заглавие на раздел; нивото на толерантност към риска, свързан с ИКТ, по Article 6(8)(b); и формалният процес за проследяване на критични одитни констатации, свързани с ИКТ, по Article 6(7).
D2. Управление и докладване на инциденти, свързани с ИКТ
Articles 17 to 23, plus RTS 2025/301
Article 17 изисква процес за управление на инциденти, свързани с ИКТ, а Article 18 определя критериите за класификация. Article 19(4) изисква първоначално уведомление, междинен доклад и окончателен доклад, но не задава часовник: той отлага сроковете към технически стандарт. Те се намират в Commission Delegated Regulation (EU) 2025/301, Article 5(1), и са най-често погрешно цитираните числа в DORA. Бъдете честни за това какво прави този първи часовник с вашия оперативен модел. Написването на уведомлението е лесната част. Трудната е, че класификацията, одобрението и подаването трябва да се случат в рамките на четири часа в който и да е ден и в който и да е час, което означава, че някой с правомощия да класифицира трябва да бъде достъпен през нощта. Това е кадрово решение и точно то тихо остава нерешено, докато наръчникът изглежда завършен.
| Оценка | Как изглежда това |
| 1 | Няма класификация, специфична за DORA. Съществуващият ITSM модел за тежест никога не е бил сравняван с критериите по Article 18. |
| 2 | Критериите за класификация са съпоставени, но не са вградени. Сроковете са известни, но не съществува изпробван работен процес, който да произведе първоначално уведомление в рамките на четири часа извън работно време. |
| 3 | Документирана процедура за класификация, съобразена с DORA, вътре в процеса за инциденти; подготвени шаблони за уведомяване; дефиниран работен процес за четирите часа и за 72 часа; и поименно посочени хора, които могат да действат по него в три сутринта. |
| 4 | Процесът е бил изпробван чрез симулация на маса или при реален инцидент. Прегледите след инцидент се връщат обратно в процедурата, а вие измервате точността на класификацията и колко близо сте били до всеки срок. |
Най-често недоразвито: пътят за ескалация извън работно време, който прави четиричасовия часовник преживяем; и доброволното уведомяване за значителни киберзаплахи по Article 19(2), което често се пропуска изцяло.
Уточнете часовника правилно. Article 5(1) от RTS 2025/301 задава три срока, като средният редовно се докладва погрешно:
- Първоначално уведомление: "в рамките на четири часа от класифицирането на инцидента, свързан с ИКТ, като голям инцидент, свързан с ИКТ, и не по-късно от 24 часа от момента, в който финансовият субект е узнал за инцидента, свързан с ИКТ".
- Междинен доклад: "най-късно в рамките на 72 часа от подаването на първоначалното уведомление".
- Окончателен доклад: "не по-късно от един месец след подаването на междинния доклад или, когато е приложимо, след последния актуализиран междинен доклад".
72 часа е срокът за междинния доклад. Ако вашият наръчник твърди друго, това само по себе си е констатация.
D3. Тестване на цифровата оперативна устойчивост
Articles 24 to 27
Article 24(1) изисква програма за тестване за финансови субекти, различни от микропредприятията, като неразделна част от рамката за управление на риска, свързан с ИКТ. Article 24(6) изисква поне веднъж годишно да се провеждат подходящи тестове на всички ИКТ системи и приложения, поддържащи критични или важни функции. Article 24(4) изисква тестовете да се извършват от независими страни, вътрешни или външни. Article 25(1) изброява видовете тестове, на които програмата може да стъпи. Тестването чрез проникване, основано на заплахи, по Article 26(1) се провежда поне веднъж на всеки три години, но само за субекти, които компетентният им орган е определил по Article 26(8).
| Оценка | Как изглежда това |
| 1 | Няма програма с обхват по DORA. Тестване чрез проникване се провежда, но никога не е било съпоставено с критичните или важните функции. |
| 2 | Тестването се случва по график, но обхватът му никога не е бил формално обвързан с функциите, които трябва да покрива, а констатациите не се проследяват до затваряне. |
| 3 | Документирана програма с обхват върху системите, поддържащи критични или важни функции, отговаряща на прага "поне веднъж годишно" по Article 24(6), използваща независими тестери съгласно Article 24(4), с проследявани констатации и писмено становище дали TLPT по Article 26 е приложимо. |
| 4 | TLPT е завършено или има пътна карта, ако субектът е определен по Article 26(8). Процедурите по Article 24(5) за приоритизиране, класифициране и отстраняване на проблеми работят доказуемо, а резултатите захранват рамката за риска. |
Най-често недоразвито: писмено и датирано определяне дали субектът е бил идентифициран за TLPT по Article 26(8), което много субекти просто никога не са правили; и проследимост на обхвата от плана за тестване обратно към критичните или важните функции, които той трябва да покрива.
D4. Управление на риска от трети страни, доставчици на ИКТ услуги
Articles 28 to 30
Article 28 изисква стратегия и политика за използването на ИКТ услуги. Article 28(8) изисква стратегии за излизане за ИКТ услуги, поддържащи критични или важни функции. Article 29 изисква предварителна оценка на риска от концентрация на ИКТ, включително дали един доставчик не е лесно заменяем. Article 30(2) изброява елементите, които всяко договорно споразумение за ИКТ трябва да съдържа, а Article 30(3) добавя допълнителни елементи, когато услугата поддържа критична или важна функция. Това е областта с най-малко контрол върху собствения си график. Четенето на договори спрямо Article 30 е кабинетна работа, която можете да планирате. Да накарате голям доставчик да приеме права на одит, ангажименти за местоположението на данните и условия за прекратяване, които не ви е предлагал миналата година, е преговор, а по-малкият субект има много малко лостове в него. Започнете тези разговори, преди прегледът на договорите да е приключил, защото прегледът ще бъде готов много преди насрещните страни да отговорят.
| Оценка | Как изглежда това |
| 1 | Няма политика за трети страни, доставчици на ИКТ услуги, специфична за DORA. Управлението на доставчици никога не е било сравнявано с Articles 28 to 30, а договорите не са преглеждани спрямо Article 30. |
| 2 | Изготвена политика, започнал но незавършен преглед на договорите и липса на документирани стратегии за излизане за критични или важни споразумения. |
| 3 | Одобрена политика; потвърдено наличие на елементите по Article 30(2) във всички споразумения и на допълнителните елементи по Article 30(3), когато услугата поддържа критична или важна функция; оценен риск от концентрация по Article 29; документирани стратегии за излизане по Article 28(8). |
| 4 | Мониторингът на доставчиците е активен, стратегиите за излизане са били не само написани, но и изпробвани, и стандартен договорен шаблон носи елементите по Article 30 по подразбиране. |
Най-често недоразвито: прегледът по Article 30 на заварени договори, подписани преди DORA да започне да се прилага; и стратегии за излизане, които действително са били тествани. Следете и броя: Article 30(2) изброява девет елемента, точки (a) до (i), а Article 30(3) добавя още за критични или важни функции. Всеки източник, който ви обещава "12 задължителни разпоредби по Article 30(2)", брои погрешно.
D5. Регистър на информацията
Article 28(3), plus ITS 2024/2956
Article 28(3) изисква регистърът да се поддържа и актуализира на ниво субект, подконсолидирано и консолидирано ниво, като обхваща всички договорни споразумения за използването на ИКТ услуги. Неговата структура идва от Commission Implementing Regulation (EU) 2024/2956: 15 шаблона, кодирани от B_01.01 до B_99.01. Тук оценявайте две неща, защото те се провалят независимо: дали данните са пълни и дали действително можете да произведете подаване, което валидира. ITS е прецизно написан и това работи в двете посоки. Едно подаване или валидира, или не, така че няма къде да скриете тънко поле зад добър разказ. Попълването на собствените ви договори е няколко седмици внимателна работа. Попълването на веригата на доставки зад тях е месец гонене на доставчици, които нямат задължение да се движат по вашия график.
| Оценка | Как изглежда това |
| 1 | Няма регистър. Данните за доставчиците стоят в електронни таблици или във вендорска система без съпоставяне с шаблоните на ITS. |
| 2 | Частично попълнен. Обикновено веригата на доставки в B_05.02 и договорните детайли в B_02.02 са тънките места, а експорт не е бил прокаран от край до край. |
| 3 | Всички 15 шаблона са попълнени, референтната цялост между тях се спазва, а пакетът е произведен и валидиран преди подаване. |
| 4 | Поддържа се целогодишно, вместо да се изгражда наново всяка година, с актуализации, задействани от договорни събития, следена валидност на LEI и подавания, които преминават валидиране без цикъл на повторно подаване. |
Най-често недоразвито: B_05.02, веригата на доставки на ИКТ услуги, където живее подвъзлагането и която почти винаги започва непълна, защото зависи от данни, които вашите доставчици трябва да предадат. Един капан: указания, които използват номерация "B00 до B14", не описват ITS. Истинските кодове вървят от B_01.01 до B_99.01.
D6. Обмен на информация
Article 45
Article 45(1) казва, че финансовите субекти могат да обменят информация и разузнавателни данни за киберзаплахи в рамките на доверени общности. Разпоредбата дава възможност, без да задължава. Оценете я въпреки това, защото документирано решение струва почти нищо, а недокументирано отсъствие изглежда като пропуск.
| Оценка | Как изглежда това |
| 1 | Няма осведоменост за Article 45 и няма оценка на наличните договорености. |
| 2 | Article 45 е оценен, релевантните договорености са идентифицирани и е записано решение за участие, но по него още не е предприето действие. |
| 3 | Активно участие в поне една договореност, с процес за приемане на постъпващото и действие по него. |
| 4 | Освен приемане има и принос, като разузнавателните данни захранват реакцията при инциденти и обхвата на програмата за тестване. |
Най-често недоразвито: нищо структурно. Това е единствената област, в която мотивирано решение да не се участва е легитимен отговор, при условие че е записано.
D7. Управление и отговорност на ръководния орган
Article 5
Article 5(2) изисква ръководният орган да определя, одобрява, наблюдава и носи отговорност за прилагането на всички механизми, свързани с рамката за управление на риска, свързан с ИКТ, след което изброява неговите конкретни задължения в точки (a) до (i). Article 5(4) изисква членовете активно да поддържат актуални знания и умения, достатъчни, за да разбират и оценяват риска, свързан с ИКТ, включително чрез редовно преминаване на специфично обучение.
| Оценка | Как изглежда това |
| 1 | Отговорностите по DORA не са възложени на ниво ръководен орган. Рискът, свързан с ИКТ, се управлява оперативно без отчетност пред съвета. |
| 2 | Съветът е осведомен и получава отчети за риска, свързан с ИКТ, но одобренията му не са документирани и не е провеждано обучение. |
| 3 | Задълженията по Article 5(2) са изпълнени и доказани: стратегията за устойчивост, одобрена по (d), политиката за непрекъснатост на дейността в областта на ИКТ и плановете за реакция и възстановяване по (e), планът за вътрешен одит на ИКТ по (f), бюджетът по (g), политиката за трети страни, доставчици на ИКТ услуги, по (h) и каналите за докладване по (i). Обучението по Article 5(4) е проведено. |
| 4 | Протоколите показват, че съветът оспорва отчетите за риска, свързан с ИКТ, вместо само да ги приема за сведение, направена е и е приложена оценка на уменията, а отговорността стои при поименно посочени лица. |
Най-често недоразвито: документираното одобрение като нещо отделно от документираната осведоменост; записите за обучение на членовете на съвета по Article 5(4); и задължението за бюджет по Article 5(2)(g), което текстът формулира като конкретно задължение.
Претегляне: нашата преценка и разсъждението зад нея
След като всяка област е оценена, претеглете пропуските. Тук трябва да сме откровени с вас: нямаме надзорни данни за това кои области привличат вниманието на правоприлагането, и никой честен източник няма такива. DORA се прилага едва от януари 2025 г. и няма публикуван корпус от правоприлагащи резултати, от който да се обобщава. Затова претеглянето по-долу не е твърдение за това върху какво се фокусират регулаторите.
То е преценка, основана на единственото нещо, за което текстът позволява да се разсъждава: колко видим и колко обвързан със срок е един провал. Пропуснат срок за докладване и отхвърлено подаване на регистъра са външно видими спрямо фиксиран часовник. Тънка рамка за риска е въпрос на надзорна оценка в по-дълъг хоризонт. Теглата произтичат именно от тази асиметрия.
| Област | Нашето тегло | Защо |
| D2 Докладване на инциденти | Критично | Четиричасов часовник, който или спазвате, или пропускате, а пропускът по конструкция е видим за надзорния орган. |
| D5 Регистър на информацията | Критично | Структурирано подаване, което или преминава валидиране, или не. Начинът на провал е двоичен и външно наблюдаем. |
| D4 Риск от трети страни, доставчици на ИКТ услуги | Високо | Съответствието с Article 30 се проверява чрез четене на договори, което прави един пропуск лесен за установяване и труден за оспорване. |
| D7 Управление | Високо | Article 50(5) позволява на държавите членки да разпрострат административните санкции и коригиращите мерки върху членовете на ръководния орган, при спазване на националното право. |
| D1 Управление на риска, свързан с ИКТ | Средно | Основополагащо, върху него стъпва всичко останало, но се оценява в по-дълъг хоризонт от един срок за подаване. |
| D3 Тестване | Средно | Твърдо годишно задължение по Article 24(6), но TLPT хапе само за субектите, определени по Article 26(8). |
| D6 Обмен на информация | По-ниско | Article 45 е позволяващ. Документирано решение е достатъчен отговор. |
Не сте съгласни с дадено тегло? Променете го. Причината да отпечатаме разсъждението до числото е за да можете да спорите с него. Претегляне, което не можете да обясните на собствения си съвет, не си струва да се внася в заседание на съвета.
От оценки към ред на работа
Сега имате две числа за всяка област: колко под 3 е нейната оценка и колко тежи тя. Пресечете ги.
Ако искате една инструкция преди таблицата: поправете първо експорта на регистъра и пътя за докладване извън работно време. И двете са евтини спрямо последиците си, и двете могат да бъдат завършени от малък екип, без да чака никого другиго, и двете се провалят по начин, който надзорният орган вижда още същата седмица. Тънък рамков документ може да се забави с тримесечие, без никой извън сградата да забележи. Пропуснат часовник не може.
Ако искате една инструкция преди таблицата: поправете първо експорта на регистъра и пътя за докладване извън работно време. И двете са евтини спрямо последиците си, и двете могат да бъдат завършени от малък екип, без да чака никого другиго, и двете се провалят по начин, който надзорният орган вижда още същата седмица. Тънък рамков документ може да се забави с тримесечие, без никой извън сградата да забележи. Пропуснат часовник не може.
| Тегло ↓ / Оценка → | Оценка 1 | Оценка 2 | Оценка 3 или по-добра |
| Критично | Незабавно. Пред ръководния орган сега, с датиран план. | Спешно. Затворете го това тримесечие. | Поддържайте и доказвайте. |
| Високо | Спешно. Затворете го това тримесечие. | Планирано. Следващото тримесечие. | Поддържайте и доказвайте. |
| Средно или по-ниско | Планирано. Следващото тримесечие. | Пътна карта. | Задържайте нивото. |
Едно правило, което си струва да закодирате твърдо: област с оценка 1 при критично или високо тегло отива при ръководния орган с обвързан със срок план, вместо в списък със задачи. Article 5(2) прави съвета отговорен за рамката, вътре в която стоят тези пропуски, така че недокладван критичен пропуск е управленски провал, натрупан върху технически.
Кога да го проведете отново
Не е нужно да измисляте ритъм. Article 6(5) ви го дава. Рамката трябва да бъде документирана и преразглеждана поне веднъж годишно, а освен това:
- При настъпване на големи инциденти, свързани с ИКТ. Голям инцидент е едновременно жив тест на D2 и сигнал, че D1 може да има пропуски, които на хартия са изглеждали добре.
- След надзорни указания. Направо от текста.
- След заключения, произтичащи от съответно тестване на цифровата оперативна устойчивост или от одитни процеси. Резултатите от тестовете са входни данни за прегледа на рамката.
Още два повода си струва да бъдат добавени. Членът не ги назовава, но те променят отговорите под краката ви: съществена промяна в средата на вашите ИКТ доставчици, която движи D4 и D5, и изменение на техническите стандарти, което може да промени какво изобщо означава оценка 3 в дадена област.
Често задавани въпроси
Изисква ли DORA gap анализ?
Не под това име и DORA никога не използва тази фраза. Това, което Article 6(5) изисква, е рамката за управление на риска, свързан с ИКТ, да бъде документирана и преразглеждана поне веднъж годишно, а също и при големи инциденти, свързани с ИКТ, и след надзорни указания или заключения, произтичащи от тестване на цифровата оперативна устойчивост или от одитни процеси. Gap анализът е обичайният инструмент за извършване на този преглед и за неговото доказване, но задължението е самият преглед.
Регулаторно изискване ли е скалата на зрелост от 1 до 4 в тази статия?
Не. DORA не предписва скала на зрелост, модел за оценяване или схема на претегляне. Четиристепенната скала, разделянето на седем области и теглата тук са наш редакционен модел, предложен, защото ви трябва някакъв последователен инструмент, за да сравнявате области. Извън редакционната част остава закотвянето на всяко ниво 3: конкретен член, за който може да ви бъде поискано доказателство. Заменете скалата със своя, ако желаете. Не заменяйте членовете, които стоят отдолу.
Кои са действителните срокове за докладване на инциденти по DORA?
Те не са в самата DORA. Article 19(4) назовава трите подавания и отлага сроковете към технически стандарт. Article 5(1) от Commission Delegated Regulation (EU) 2025/301 ги задава: първоначалното уведомление в рамките на четири часа от класифицирането на инцидента като голям и не по-късно от 24 часа от узнаването за него; междинният доклад най-късно в рамките на 72 часа от първоначалното уведомление; и окончателният доклад не по-късно от един месец след междинния доклад или след последния актуализиран междинен доклад, когато е приложимо. Обърнете внимание, че 72 часа се отнасят за междинния доклад. Много често и погрешно те се представят като срок за окончателния.
Колко договорни разпоредби изисква Article 30(2)?
Девет. Article 30(2) изброява точки (a) до (i): описание на функциите и ИКТ услугите и условията за подизпълнение; местата, където се предоставят услугите и се обработват данните; разпоредби за защита на данните; разпоредби за достъп, възстановяване и връщане на данни; описания на нивото на услугата; задължения за съдействие при инциденти; сътрудничество с компетентните органи; права за прекратяване и срокове за предизвестие; и участие в обученията на субекта по осведоменост за ИКТ сигурността и по устойчивост. Article 30(3) след това добавя допълнителни елементи, когато споразумението поддържа критична или важна функция. Gap анализ, който оценява спрямо списък от 12 "разпоредби по Article 30(2)", оценява спрямо списък, който не съществува в регламента.
Можем ли да преизползваме нашата ISO 27001 оценка като DORA gap анализ?
Частично, и границата е рязка. Една ISO 27001 оценка ви дава реален сигнал за D1 и D3, защото подлежащата материя по управление на сигурността се припокрива. Тя не ви дава нищо за D5, защото регистърът на информацията е отчетен документ, определен от регламент за изпълнение на ЕС, който няма ISO аналог. Тя не ви дава нищо за специфичните за DORA части на D4, в частност договорните елементи по Article 30, нищо за критериите за класификация по Article 18 и часовника за докладване в D2, и нищо за задълженията на ръководния орган по Article 5(2) в D7. Преизползвайте това, което наистина се припокрива, след което оценете останалото спрямо членовете.
Каква оценка трябва да си поставим за цел?
Оценка 3 във всяка област означава, че отговаряте на изискванията така, както са написани, и можете да го докажете, което е прагът, който регулацията действително поставя. Стремете се към 4 там, където провалът е обвързан със срок и външно видим, което в нашето претегляне означава D2 и D5. Но целта, която има по-голямо значение от всяко число: нито една област да не стои на 1 без датиран план пред ръководния орган.
Първични източници
Всеки номер на член, срок и брой в тази статия е сверен с текстовете по-долу. Проверете текущата версия, преди да разчитате на конкретен параграф.
- Regulation (EU) 2022/2554 (DORA) - Articles 5, 6, 17 to 19, 24 to 27, 28 to 30, 45 and 50. Съдържа 64 члена и се прилага от 17 януари 2025 г.
- Commission Delegated Regulation (EU) 2025/301 - Article 5(1) задава сроковете от четири часа, 72 часа и един месец за докладване.
- Commission Implementing Regulation (EU) 2024/2956 - ITS за регистъра на информацията, който задава 15-те шаблона от B_01.01 до B_99.01.
- Commission Delegated Regulation (EU) 2024/1774 - RTS за инструментите, методите, процесите и политиките за управление на риска, свързан с ИКТ.
Провеждане на оценката във Venvera
Venvera има модул за gap анализ и си струва да бъдем точни какво прави той. Той провежда оценявана проверка спрямо дадена рамка, произвежда обща оценка и превръща всеки пропуск в план за отстраняване с приоритет, отговорник и краен срок, така че резултатът е проследяван план вместо електронна таблица, която тихо остарява. Днес покрива DORA и NIS2, а DORA оценките идват в пълен вариант и във вариант за микросубекти. Това е границата и предпочитаме да я заявим, вместо да намекваме за по-широка.
DORA е един от няколкото режима, които повечето финансови субекти носят едновременно, а работата се припокрива силно. Crosswalk механизмът съществува, за да може контрол, който сте доказали веднъж, да удовлетвори своите съответствия по NIS2 или ISO 27001, вместо да бъде изграждан наново от нулата. За по-бърз поглед къде стоите, преди да поемете ангажимент, направете безплатна проверка на съответствието.
Оценете готовността си, след което проследявайте отстраняването
Оценяван gap анализ, планове за отстраняване с отговорници и дати и доказателства, съхранявани там, където одиторът може да ги намери.
Заявете демо →Последна актуализация: юли 2026 г. Обща информация, не представлява правен съвет. Скалата на зрелост, разделянето на седем области и теглата в тази статия са редакционен модел на Venvera и нямат силата на регулаторни изисквания. Сверете препратките към членовете с текущия текст и с указанията на вашия компетентен орган.
