Какво е DORA и откога се прилага?

DORA (Digital Operational Resilience Act) е регламент на ЕС (Регламент 2022/2554), който създава единна рамка за управление на ИКТ риска във финансовия сектор. Той влиза в сила на 16 януари 2023 г. и се прилага от 17 януари 2025 г. DORA обхваща банки, застрахователни дружества, инвестиционни посредници, платежни институции, доставчици на услуги за криптоактиви и критични трети страни, доставчици на ИКТ услуги, които оперират в ЕС. Регламентът въвежда задължителни изисквания за управление на ИКТ риска, докладване на инциденти, тестване на устойчивостта, надзор върху риска от трети страни и обмен на информация.

Кой трябва да спазва DORA?

DORA се прилага за над 22 000 финансови субекта в ЕС, включително кредитни институции (банки), застрахователни и презастрахователни предприятия, инвестиционни посредници, платежни институции, дружества за електронни пари, доставчици на услуги за криптоактиви (CASP), централни депозитари на ценни книжа, места за търговия, управители на фондове (UCITS и AIFM), агенции за кредитен рейтинг и доставчици на услуги за колективно финансиране. Регламентът определя и критични трети страни, доставчици на ИКТ услуги (CTPP), които обслужват тези субекти. Ако вашата организация има лиценз за финансови услуги в държава членка на ЕС или предоставя критични ИКТ услуги на такива, които имат, DORA се отнася за вас.

Какво представлява Register of Information по DORA?

Register of Information е задължителен структуриран запис на всички договорни отношения с трети страни, доставчици на ИКТ услуги, изискван съгласно DORA Article 28(3). Финансовите субекти трябва да поддържат този регистър на ниво субект, подконсолидирано и консолидирано ниво. Той трябва да документира всяко отношение с доставчик на ИКТ услуги, включително естеството на услугата, дали тя поддържа критични или важни функции, местата на обработване на данни, веригите от подизпълнители и стратегиите за изход. Регистърът се предоставя на компетентните органи при поискване. Venvera генерира този регистър автоматично от вашите данни за доставчици и договори и го експортира във формата xBRL-CSV, изискван от EBA, за всички 15 задължителни таблици.

Какво е xBRL-CSV и защо DORA го изисква?

xBRL-CSV (Extensible Business Reporting Language във формат CSV) е техническият формат за отчитане, определен от Европейския банков орган (EBA) за подаване на Register of Information по DORA. Той се състои от 15 взаимосвързани CSV таблици, които покриват идентификация на субекта, трети страни, доставчици на ИКТ услуги, договорни отношения, поддържани функции, местоположения на данните и вериги от подизпълнители. Всяка таблица следва строги дефиниции на полета, контролирани речници и правила за кръстосано препращане, определени в техническите стандарти на EBA. Ръчното изграждане на тези файлове в електронни таблици води до грешки заради зависимостите между таблиците и правилата за валидиране. Venvera генерира всички 15 xBRL-CSV таблици автоматично от данните във вашата платформа с вградено валидиране.

Как се преминава надзорна оценка по DORA?

Надзорните органи оценяват съответствието с DORA, като разглеждат пет стълба: вашата рамка за управление на ИКТ риска (Article 6), способностите за докладване на инциденти (Article 19), програмата за тестване на цифровата оперативна устойчивост (Article 24), управлението на ИКТ риска от трети страни, включително Register of Information (Article 28), и договореностите за обмен на информация (Article 45). За да преминете, са ви нужни документирани политики, пълен и актуален Register of Information, доказателства за класифициране и докладване на инциденти в изискваните срокове, програма за тестване, пропорционална на вашия рисков профил, и надзор на ниво ръководен орган с документирана отчетност. Venvera предоставя структурирани работни процеси, одитни следи и експортируеми пакети с доказателства за всеки стълб.

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

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

Какво е личната отговорност на членовете на борда по DORA Article 5(2)?

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

NEWVenvera говори вашия език: цялата платформа на английски, немски, испански, български, арабски и китайски.Вижте новото →

Съответствие с DORA

DORA е закон. А глобата носи вашето име.

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

Управление на ИКТ рискаДокладване на инцидентиТестване на устойчивосттаРиск от трети страниОбмен на информация

Вземете безплатния доклад за пропуските →Запазете 15-минутно демо Вижте какво вече имате ↓

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

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

Вече прилагате

Трябва да добавите

27 от 55 области в това съпоставяне присъстват и в NIS2, и в DORA.

Област	NIS2	DORA
Криптиране	Art. 21(2)(h)Има ли политики и процедури, които уреждат използването на криптография, включително стандарти за криптиране на данните в покой и при пренос?	Art. 9(4)(d)Криптирани ли са данните в покой и при пренос с утвърдени в отрасъла криптографски техники и документирани ли са процедурите за управление на ключовете?
Контрол на достъпа	Art. 21(2)(i)Има ли формална политика за контрол на достъпа, която налага принципа на най-малките привилегии, с документирани процедури за предоставяне и отнемане на достъп?	Art. 9(4)(c)Има ли формална политика за управление на идентичността и достъпа, която налага принципа на най-малките привилегии, многофакторно удостоверяване за критичните системи и редовно повторно потвърждаване на достъпа?
Управление на идентичността	Art. 21(2)(i)Има ли формална политика за контрол на достъпа, която налага принципа на най-малките привилегии, с документирани процедури за предоставяне и отнемане на достъп?	Art. 9(4)(c)Има ли формална политика за управление на идентичността и достъпа, която налага принципа на най-малките привилегии, многофакторно удостоверяване за критичните системи и редовно повторно потвърждаване на достъпа?
Удостоверяване и MFA	Art. 21(2)(j)Внедрено ли е многофакторно удостоверяване или непрекъснато удостоверяване за достъпа до критичните системи, отдалечения достъп и привилегированите акаунти?	Art. 9(4)(c)Има ли формална политика за управление на идентичността и достъпа, която налага принципа на най-малките привилегии, многофакторно удостоверяване за критичните системи и редовно повторно потвърждаване на достъпа?
Мрежова сигурност	Art. 21(2)(g)Установени ли са и налагат ли се основни практики за киберхигиена, включително инсталиране на корекции, политики за пароли, управление на устройствата и сегментиране на мрежата?	Art. 9(4)(b)Внедрени ли са контроли за мрежова сигурност (сегментиране, защитни стени, предотвратяване на прониквания) за защита на ИКТ системите, с редовен преглед и укрепване на защитата?
Управление на уязвимостите	Art. 21(2)(e)Има ли процес за обработване и разкриване на уязвимости, който гарантира своевременното им идентифициране, оценка и отстраняване?	Art. 9(4)(a)Има ли формален процес за управление на корекциите и уязвимостите, който гарантира своевременното отстраняване на установените уязвимости във всички ИКТ системи?
Журналиране и наблюдение	Art. 21(2)(f)Определени ли са метрики за сигурност и KPI, проследяват ли се и докладват ли се на ръководството, за да се измерва ефективността на контролите за киберсигурност?	Art. 10(1)–(4)Разполагате ли с възможности за непрекъснато наблюдение и откриване (SIEM, IDS/IPS, откриване на аномалии) за своевременно идентифициране на инциденти, свързани с ИКТ, и аномални дейности?
Управление на инциденти	Art. 21(2)(b)Има ли документирана процедура за обработване на инциденти, която обхваща етапите на откриване, анализ, ограничаване, премахване и възстановяване?	Art. 17(1)–(2)Имате ли документиран процес за управление на инциденти, свързани с ИКТ, който обхваща откриване, регистриране, класифициране, ескалация, реагиране и приключване?
Класифициране на инциденти	Art. 23(3)Документирани ли са критериите за класифициране на инциденти, които разграничават значителните инциденти според въздействието върху предоставянето на услуги, засегнатите потребители, продължителността и географския обхват?	Art. 18(1)Класифицират ли се инцидентите като големи или неголеми по документирани критерии, съобразени с праговете по DORA? Art. 18(1)(a)–(g)Отчита ли класифицирането всички количествени критерии по DORA: брой засегнати клиенти, стойност на транзакциите, продължителност, географско разпространение, загуба на данни, критичност на засегнатите услуги и икономическо въздействие?
Докладване на инциденти	Art. 23(4)(a)–(b)Може ли вашата организация да подаде ранно предупреждение до CSIRT в рамките на 24 часа и уведомление за инцидент в рамките на 72 часа, след като е узнала за значителен инцидент?	Art. 19(4)(a)Може ли вашата организация да подаде първоначално уведомление за инцидент до компетентния орган в рамките на 4 часа от класифицирането на инцидент, свързан с ИКТ, като голям? Art. 19(4)(b)–(c)Имате ли процеси и шаблони за подаване на междинния доклад (в рамките на 72 часа) и окончателния доклад (в рамките на 1 месец) за големи инциденти, свързани с ИКТ?
Екип за реагиране при инциденти	Art. 21(2)(b)Има ли документирана процедура за обработване на инциденти, която обхваща етапите на откриване, анализ, ограничаване, премахване и възстановяване?	Art. 17(2)Създаден ли е специален екип за реагиране при инциденти с определени роли, пътища за ескалация, процедури за дежурство и правомощия да действа при инциденти, свързани с ИКТ?
Преглед след инцидент	Art. 21(2)(b)Извършвате ли прегледи след значителни инциденти с анализ на първопричината, като извлечените поуки се използват за подобряване на управлението на риска?	Art. 17(3)Извършвате ли формални прегледи след инцидент с анализ на първопричината за всички големи инциденти, свързани с ИКТ, като констатациите се връщат в рамката за управление на риска?
Непрекъснатост на дейността	Art. 21(2)(c)Документирани ли са плановете за непрекъснатост на дейността и за възстановяване след бедствие за всички критични услуги, с определени цели за RTO/RPO, и тестват ли се поне веднъж годишно?	Art. 11(1)–(11)Документирани ли са плановете за непрекъснатост на ИКТ дейността и за възстановяване след бедствие, тествани поне веднъж годишно и одобрени от ръководството, и обхващат ли всички критични бизнес функции?
Резервно копиране и възстановяване	Art. 21(2)(c)Прилагат ли се процедури за резервно копиране с определени обхват, честота и сигурно съхранение извън основната площадка, с редовно тестване на възстановяването?	Art. 12(1)–(7)Поддържате ли политики за резервно копиране и възстановяване, които определят обхвата, честотата и сигурните места за съхранение, с редовно тестване на възстановяването?
Управление на кризи	Art. 21(2)(c)Има ли рамка за управление на кризи с определени процедури за ескалация, комуникационни планове и определен екип за управление на кризи?	Art. 14(1)–(2)Документирани ли са плановете за кризисна комуникация в областта на ИКТ, които определят процедурите за вътрешно и външно уведомяване, ролите и политиките за отговорно оповестяване?
Управление на риска от трети страни	Art. 21(2)(d)Има ли документирана политика за сигурност на веригата на доставки, която обхваща придобиването на ИКТ продукти и услуги и съдържа изисквания за сигурност към доставчиците?	Art. 28(2)Одобрил ли е ръководният орган стратегия за ИКТ риска от трети страни, която е съгласувана с цялостната рамка за управление на ИКТ риска и се преглежда поне веднъж годишно?
Надлежна проверка на доставчиците	Art. 21(2)(d)Оценявате ли нивото на киберсигурност и практиките на преките доставчици и доставчиците на услуги, преди да сключите споразумения с тях?	Art. 28(4)Извършват ли се задълбочена надлежна проверка и оценка на риска, преди да се сключат нови договорености с доставчици на ИКТ услуги, трети страни, особено за критични или важни функции?
Договори с доставчици	Art. 21(2)(d)Включват ли договорите с доставчици изисквания за киберсигурност, задължения за уведомяване за инциденти и права на одит/оценка?	Art. 30(2)(a)Включват ли договорите с доставчици на ИКТ услуги, трети страни, ясни споразумения за ниво на обслужване (SLA) с количествени цели за изпълнението, мерки за наблюдение и последици при неспазване? Art. 30(3)(e)Включват ли договорите за ИКТ услуги, поддържащи критични или важни функции, неограничени права на одит и проверка, включително достъп на място и използване на съвместни одити?
Наблюдение на доставчиците	Art. 21(2)(d)Наблюдават ли се текущо рисковете във веригата на доставки и представянето на доставчиците в областта на киберсигурността, с периодична повторна оценка?	Art. 28(5)Подлежат ли доставчиците на ИКТ услуги, трети страни, които поддържат критични или важни функции, на непрекъснато наблюдение и на формални прегледи на изпълнението поне веднъж годишно?
Оценка на риска	Art. 21(2)(a)Има ли формална, документирана методология за анализ на риска, която идентифицира и оценява рисковете за киберсигурността на мрежовите и информационните системи?	Art. 8(2)–(6)Има ли формален процес за идентифициране и оценка на ИКТ риска, който се изпълнява поне веднъж годишно, след съществени промени и след големи инциденти, свързани с ИКТ?
Политика за информационна сигурност	Art. 21(2)(a)Одобрил ли е ръководният орган изчерпателна политика за информационна сигурност, която обхваща всички мрежови и информационни системи и се преглежда поне веднъж годишно?	Art. 9(1)–(2)Документирани ли са изчерпателни политики и стандарти за ИКТ сигурност, одобрени от ръководството и съобщени на всички служители, и преглеждат ли се редовно?
Обучение за осведоменост по сигурността	Art. 20(2), Art. 21(2)(g)Има ли програма за осведоменост и обучение по киберсигурност за всички служители, включително членовете на ръководния орган, с редовни опреснителни обучения?	Art. 13(6)Има ли програма за осведоменост и обучение по ИКТ сигурност, която обхваща всички служители (включително ръководството), актуализира се редовно и включва специфичните задължения по DORA?
Управление на промените	Art. 21(2)(e)Има ли формален процес за управление на промените в мрежовите и информационните системи, който включва оценка на въздействието върху сигурността и тестване?	Art. 9(4)(e)Въведени ли са процедури за управление на промените в ИКТ, които гарантират контролирани, тествани и одобрени промени в ИКТ системите и приложенията?
Тестване на сигурността	Art. 21(2)(f)Има ли определени политики и процедури за оценка на ефективността на мерките за управление на риска в областта на киберсигурността, включително редовно тестване на сигурността?	Art. 24(1)–(2)Създали ли сте програма за тестване на цифровата оперативна устойчивост, която се основава на риска, обхваща критичните ИКТ системи и се преглежда поне веднъж годишно?
Тестване за проникване	Art. 21(2)(f)Има ли определени политики и процедури за оценка на ефективността на мерките за управление на риска в областта на киберсигурността, включително редовно тестване на сигурността?	Art. 25(1)Провеждат ли се поне веднъж годишно тестове за проникване на критичните ИКТ системи, които симулират реални сценарии на атака?
Уведомяване за нарушения	Art. 23(4)(a)–(b)Може ли вашата организация да подаде ранно предупреждение до CSIRT в рамките на 24 часа и уведомление за инцидент в рамките на 72 часа, след като е узнала за значителен инцидент?	Art. 19(4)(a)Може ли вашата организация да подаде първоначално уведомление за инцидент до компетентния орган в рамките на 4 часа от класифицирането на инцидент, свързан с ИКТ, като голям?
Човешки надзор	Art. 20(1)Получава ли ръководният орган редовни (поне веднъж на тримесечие) доклади за рисковата позиция в областта на киберсигурността и напредъка по третирането на риска?	Art. 5(1)–(2)Определил ли е и одобрил ли е ръководният орган рамка за управление на ИКТ риска с ясни роли, отговорности и линии на докладване и поел ли е крайната отговорност за нея?

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

Какво е DORA и защо не можете да го подминете?

Digital Operational Resilience Act (Регламент 2022/2554) е закон на ЕС, в сила от 17 януари 2025 г., който обвързва над 22 000 финансови субекта: банки, застрахователи, инвестиционни посредници, платежни институции и доставчици на услуги за криптоактиви. Това е задължителен режим: вашият национален компетентен орган очаква Register of Information, подаден във формата xBRL-CSV на ESA, а по Article 5 вашият ръководен орган отговаря лично за рамката за управление на ИКТ риска. При пропуснато подаване или пропуснат срок за инцидент отговорността се носи поименно от конкретни лица наред с дружеството.

/ DORA · всеки стълб на един готов за одит екран

xBRL-CSV таблици, генерирани автоматично

4 ч

Срок за класифициране на инцидент, следен автоматично

5(2)

Член за отговорността на борда, доказан

5 мин

Време за завършване на оценката на пропуските

Article 28 · ексклузивно

xBRL-CSV експорт с един клик. Никоя друга платформа не го предлага.

Това е частта, която платформите за съответствие, изградени в САЩ, просто нямат. Те съпоставят DORA със съществуващата си библиотека от контроли и спират дотам, като нито една от тях не генерира файла EBA xBRL-CSV, който вашият национален компетентен орган реално изисква. Venvera го генерира. Вашият регистър се изгражда от доставчиците и договорите, които вече следите: всяка трета страна, доставчик на ИКТ услуги, всяко договорно отношение, поддържана функция и верига от подизпълнители се съхраняват като структурирани полета, които се съпоставят директно с 15-те таблици на EBA. Когато прозорецът за подаване се отвори, експортирате и 15-те таблици с валидирани кръстосани препратки за секунди, точно във формата, който вашият регулатор приема. Без ръчно сглобяване на CSV файлове, без счупени външни ключове и без надпревара в последната минута.

Естествен xBRL-CSV експорт във формата на EBA, уникален за Venvera и недостъпен в инструментите, изградени в САЩ
Всички 15 таблици на EBA се генерират автоматично от данните във вашата платформа
Валидирането между таблиците улавя грешките, преди да подадете
Регистри на ниво субект, подконсолидирано и консолидирано ниво
Проследяване на веригата от подизпълнители с видимост до n-та страна

/ xBRL-CSV ЕКСПОРТ · 15 валидирани таблици с един клик, само във Venvera

Article 6

Регистър на ИКТ рисковете, който изпълнява Article 6 вместо вас.

Централизиран регистър на рисковете, създаден специално за DORA Article 6. Всеки ИКТ риск се оценява по матрица 5x5 вероятност спрямо въздействие с автоматично класифициране от нисък до критичен. Възлагайте отговорност, задавайте дати за преглед, проследявайте решенията за третиране и генерирайте доклади, готови за борда, с един клик, с пълна одитна следа върху всяка промяна, която покрива надзорните изисквания за доказателства.

Автоматично оценяване на риска 5x5 с проследяване на присъщ и остатъчен риск
9 категории ИКТ риск, съгласувани с таксономията на DORA
Прагове на рисковия апетит с автоматични тригери за ескалация
Съпоставяне на контроли между рамки към NIS2, ISO 27001 и GDPR
Тримесечни моментни снимки на риска за анализ на тенденции и одитни доказателства

/ ИКТ РИСК · оценяване 5x5, пълна одитна следа

Article 19

Часовници за инциденти, които се пускат сами.

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

Автоматично класифициране на инциденти спрямо критериите за тежест по DORA
Таймери за обратно броене за сроковете от 4 часа, 72 часа и 1 месец
Предварително форматирани шаблони за първоначален, междинен и окончателен доклад
Работни процеси за ескалация при наближаващи срокове
Пълна хронология на инцидента с одитна следа за надзорен преглед

/ ИНЦИДЕНТИ · 4 ч / 72 ч / 1 мес., следени до минутата

Article 28

Открийте своя риск от концентрация преди регулатора.

Article 28 изисква да управлявате ИКТ риска от трети страни през цялото отношение с доставчика. Venvera оценява всеки доставчик по пет претеглени измерения: критичност, географски риск, концентрация, състояние на договора и чувствителност на данните, и маркира единичните точки на отказ, преди надзорният орган да попита за тях. Стратегиите за изход, оценките за заменяемост и веригите от подизпълнители се съхраняват на едно място.

Автоматично оценяване на риска по пет измерения за всеки доставчик
Сигнали за риск от концентрация на ниво държава и доставчик
Документиране на стратегия за изход с оценка на заменяемостта
Картографиране на веригата от подизпълнители с проследяване до n-та страна
Наблюдение на жизнения цикъл на договора: изтичане, SLA, права за одит

/ РИСК ОТ ТРЕТИ СТРАНИ · концентрацията е видима, изходите са документирани

Article 5(2)

Досието с доказателства, което защитава вашия борд.

Article 5(2) прави членовете на борда лично отговорни за рамката за управление на ИКТ риска, затова е важно да можете да докажете как са упражнили този надзор. Venvera проследява всеки елемент от надзора на борда: одобрения на политики, прегледи на доклади за риска, решения за разпределяне на ресурси, завършени обучения и присъствие на заседания, всичко на един дашборд, с пакет доказателства за отговорност, експортируем за всеки член на борда.

Проследяване на одобренията на политики с записи за дигитално подписване
Регистриране на присъствие на заседания на борда и точки от дневния ред
Документиране на разпределянето на ресурси за бюджетите за ИКТ риск
Записи за завършени обучения на членовете на ръководния орган
Пакет с доказателства за лична отговорност, експортируем за всеки член на борда

/ БОРД · надзорът по Article 5(2), доказан

Готовност

Знайте точно къде сте за пет минути.

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

Оценка по пет стълба, покриваща всички изисквания на DORA
Оценяване на зрелостта: незапочнато, частично, внедрено, ефективно
Автоматично генерирана пътна карта за отстраняване с приоритети и оценки на усилието
Възлагане на отговорност и следене на срокове за всяка мярка
Дашборд за напредъка, който показва траекторията на съответствието във времето

/ ОЦЕНКА НА ПРОПУСКИТЕ · пет стълба, оценени и приоритизирани

Защо да смените

Таблицата или Venvera.

Електронни таблици

Venvera

Ръчно сглобяване на CSV, счупени кръстосани препратки

Автоматично генерирани 15 xBRL-CSV таблици с валидиране

Оценяване на ИКТ риска

Формули в таблици, непоследователна методология

Автоматизирана матрица 5x5 с одитна следа

Докладване на инциденти

Вериги от имейли, ръчно следене на сроковете

Таймери 4 ч / 72 ч / 1 мес. с автоматична ескалация

Риск от трети страни

Списък с доставчици без оценяване и изглед за концентрация

Автоматично оценяване по 5 измерения със сигнали за концентрация

Надзор от борда

Липсва доказателствена следа за Article 5(2)

Дигитални подписвания, записи за обучения, дневник на надзора

Оценка на пропуските

Еднократен ангажимент с консултант, статичен PDF

Жива оценка с пътна карта и проследяване на напредъка

DORA, с отговори.

Разберете къде сте по DORA преди вашия национален орган.

Започнете с безплатен доклад за пропуските по всички области на DORA - 10 минути, без имейл в началото.

Вземете безплатния доклад за пропуските →Запазете 15-минутно демо

✓ Във всеки платен план: готови за одит за 90 дни или връщаме парите^*

10 минути · без имейл, за да започнете · без кредитна карта · остава ваше