Какво представлява регламентът DORA? Обяснение на Акта на ЕС за цифрова оперативна устойчивост

Регламентът DORA — Актът за цифрова оперативна устойчивост — е законът на ЕС за киберустойчивостта на финансовия сектор. Той определя как финансовите институции да управляват рисковете за киберсигурността и IT. Казано просто, всяка банка, платежна компания, инвестиционен посредник, застраховател и криптоборса в ЕС трябва да може да продължи работа при хакерска атака, срив на облачна услуга или неуспешна софтуерна актуализация и да следи IT доставчиците, от които зависи.

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

Какво представлява DORA накратко?

DORA — понякога изписван като EU DORA или Законът DORA — е Регламент (ЕС) 2022/2554 относно цифровата оперативна устойчивост на финансовия сектор. „Цифрова оперативна устойчивост“ звучи сложно, но означава едно: може ли вашата компания да продължи да обслужва клиентите си, когато IT системите ѝ дадат дефект? Ако хакер проникне, актуализация се провали или доставчик прекъсне работа — продължават ли плащанията, могат ли клиентите да влизат в профилите си, защитени ли са данните им? DORA превръща този въпрос от добра практика в правно задължение.

Преди DORA всяка държава от ЕС и всяка част от финансовия сектор имаше собствени правила за IT сигурност и собствени формуляри за инциденти. DORA заменя тази разпокъсаност с единен набор от правила за целия финансов сектор на ЕС. Тъй като е регламент, а не директива, той се прилага дословно във всяка държава членка — не е необходим национален закон, за да влезе в сила.

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

• управление на ICT риска — писмен план за IT риска, за който отговаря ръководният орган (съветът);
• управление и докладване на инциденти, свързани с ICT — откриване, регистриране и докладване на IT инциденти на надзорния орган;
• тестване на цифровата оперативна устойчивост — от рутинно сканиране за уязвимости до пълни симулации на атаки тип „red team“;
• управление на риска от трети страни в ICT — контрол на IT доставчиците, от които дружеството зависи, с регистър на всички тях;
• споделяне на информация — доброволен обмен на информация за заплахи между финансови субекти.

Обяснение на ключовите термини в DORA

Няколко дефинирани термина се срещат във всеки член на регламента DORA, всеки надзорен формуляр и всеки договор с доставчик. След като ги усвоите, останалата част се чете много по-лесно.

За кого се прилага DORA?

Обхватът на DORA е определен в член 2, който изброява двадесет категории финансови субекти. Ако финансова институция притежава някой от тези лицензи навсякъде в ЕС, тя попада в обхвата — независимо колко е малка — освен ако не важи конкретно изключение. Основните групи са по-долу.

А какво става със самите IT компании? Облачните платформи, центровете за данни, доставчиците на софтуер и фирмите за управлявана сигурност не са финансови субекти, но DORA ги обхваща по два начина. Първо, всеки финансов субект трябва да включи в договорите с тях условия по модела на DORA, така че доставчик, който откаже, рискува да загуби клиента. Второ, най-големите доставчици — големи доставчици на облачни услуги, центрове за данни, телекоми и доставчици на финансов софтуер — се определят като критични доставчици на ICT услуги — трети страни и се надзирават пряко на равнище ЕС; списъкът се актуализира всяка година.

Прилага ли се DORA за компании извън ЕС? Пряко — само за дружества, лицензирани в ЕС, включително дъщерните дружества и клоновете в ЕС на британски, американски или азиатски групи. Непряко той обхваща всеки чуждестранен доставчик, който обслужва финансова фирма от ЕС, защото задължителните договорни клаузи важат независимо къде е установен доставчикът. Доставчик извън ЕС, определен като критичен, трябва да учреди дъщерно дружество в ЕС в срок от дванадесет месеца.

Накрая, DORA е пропорционален: задълженията нарастват според размера и сложността на финансовата институция. Микропредприятията — с под десет служители и под два милиона евро оборот или балансова сума — не изпълняват няколко изисквания, включително TLPT и някои задължения за управление и докладване. Определена група по-малки дружества, като малки и невзаимосвързани инвестиционни посредници и някои освободени платежни институции и институции за електронни пари, следва опростена рамка за управление на ICT риска по член 16. Малкият размер не изключва лицензирано дружество от DORA; той само облекчава тежестта.

Изисквания на DORA: петте стълба

Изискванията за съответствие с DORA попадат в пет групи. Заедно те образуват един цикъл — предотвратяване, откриване, реагиране, възстановяване, извличане на поуки — и регулаторът очаква доказателства за всяка стъпка.

Рамка за управление на ICT риска (членове 5–16)

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

Докладване на инциденти: сроковете от 4 часа, 72 часа и един месец

Всеки инцидент, свързан с ICT, трябва да бъде регистриран и класифициран по едни и същи критерии в целия ЕС: колко клиенти са засегнати, колко е увредена репутацията на дружеството, колко е продължил, колко широко се е разпространил, какви данни са загубени, колко критична е услугата и какви средства са заложени. Инцидент, който преминава праговете, е „сериозен“ и трябва да се докладва на надзорния орган на три етапа: първоначално уведомление в рамките на четири часа след определянето му като сериозен (и не по-късно от 24 часа след като дружеството е узнало за него), междинен доклад в рамките на 72 часа от първото уведомление и окончателен доклад в рамките на месец от междинния. Клиентите, чиито средства или данни са засегнати, трябва да бъдат уведомени незабавно. Сериозни киберзаплахи, които не са прераснали в инциденти, могат да се докладват доброволно.

Тестване на устойчивостта и пенетрационно тестване, основано на заплахи (TLPT)

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

Риск от трети страни, възлагане на външни изпълнители и регистър на информацията

Възлагането на IT на външен изпълнител — доставчик на облачни услуги или друг — не възлага на външен изпълнител отговорността. Управлението на риска от трети страни в ICT започва с писмена стратегия за риска от доставчиците; дружеството трябва да проверява доставчиците преди подписване, да избягва прекомерната зависимост от един доставчик и да поддържа регистър на информацията — структуриран списък на всеки IT договор — който се подава на надзорния орган поне веднъж годишно. Самите договори трябва да съдържат определен набор от клаузи: каква е услугата и какво ниво е обещано, къде се съхраняват данните, право на проверка и одит, задължение за съдействие при инциденти, как договорът може да бъде прекратен и как дружеството би преминало към друг доставчик при необходимост. Дружеството остава изцяло отговорно, дори когато доставчикът е критичен и е надзираван на равнище ЕС.

Споделяне на информация за киберзаплахи

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

DORA срещу NIS2 срещу GDPR: как се съчетават правилата

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

На практика финансова фирма докладва IT инциденти на своя финансов надзорен орган, а не на националната агенция за киберсигурност. GDPR се прилага паралелно: ако кибератака разкрие клиентски данни, фирмата докладва два пъти — по DORA на финансовия надзорен орган и по GDPR на органа за защита на данните — по два отделни срока.

DORA и крипто: какво означава за CASP и емитентите на токени

За криптобизнеса регламентът DORA и рамката MiCA работят като двойка. MiCA определя кой може да предоставя криптоуслуги или да емитира токени в ЕС; DORA определя как трябва да се управлява технологията зад тези услуги. Доставчик на услуги за криптоактиви, лицензиран по MiCA, е финансов субект по DORA от момента на издаване на лиценза, както и всеки емитент на токени, обезпечени с активи. Самият MiCA препраща към DORA за изискванията за IT и сигурност, затова всеки надзорен орган ги разглежда заедно.

На практика устойчивостта се проверява още по време на лицензионния процес, а не само след това. Когато надзорният орган разглежда заявление на CASP, рамката за IT риск, планът за непрекъсваемост на дейността, процедурите за инциденти и договореностите за възлагане на външни изпълнители са част от документацията, а DORA е критерият, по който се оценяват. Криптоборса или попечител не може да получи — или да запази — лиценза си с план за устойчивост, който съществува само на хартия.

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

Санкции, глоби и наказания по DORA при неспазване

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

Може да сте виждали „глоба по DORA“ в размер на един процент от средния дневен световен оборот. Тази цифра е реална, но е насочена към друг субект: това е дневната санкция, която европейските надзорни органи могат да наложат на критичен доставчик на ICT услуги — трета страна, който не изпълнява решение за надзор, за срок до шест месеца. Това не е глоба за банки или криптокомпании. Понякога цитираният заедно с нея „2% от годишния оборот“ също не е в DORA: той идва от NIS2, където е минималният праг, който държавите трябва да определят за съществените субекти. За финансова фирма реалистичните последици са:

• надзорни мерки — разпореждания за отстраняване на проблеми, ограничения на дейността и в тежки случаи спиране или отнемане на лиценза;
• административни глоби по националното законодателство на сектора;
• лична отговорност на членовете на съвета, защото DORA прави съвета отговорен за IT рамката;
• наказателна отговорност в държавите, избрали да я въведат, което член 52 допуска;
• репутационни и търговски вреди — загубени клиенти, банкови партньори и инвеститори.

Кой надзирава DORA? Регулатори на национално равнище и равнище ЕС

Ежедневният надзор по DORA остава при регулатора, който вече лицензира дружеството — централната банка или органа за финансов надзор в неговата държава членка по произход. Този компетентен орган получава докладите за инциденти и регистрите на информацията, определя кой трябва да извършва TLPT и проверява рамката за IT риск като част от обичайния надзор. Повечето публикуват на уебсайтовете си насоки, образци и срокове по DORA.

На равнище ЕС три органа споделят работата: Европейският орган за ценни книжа и пазари, Европейският банков орган и EIOPA, органът за застраховане и професионално пенсионно осигуряване. Те изготвят техническите стандарти, които уреждат подробностите, и съвместно определят критичните доставчици на ICT услуги — трети страни, всеки от които след това се надзирава от един от трите като водещ надзорник.

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

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

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

Eesti Firma консултира финтех и криптокомпании по правните аспекти на DORA: определяне на приложимите задължения, съгласуване на IT рамката с изискванията за лицензиране по MiCA, преглед на договори с доставчици и подготовка на документите, които надзорният орган очаква да види. Свържете се с нас, за да обсъдим как регламентът се прилага за вашия бизнес.

Заявете консултация

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