DORA — Digital Operational Resilience Act — a devenit aplicabil integral pe 17 ianuarie 2025 în orice entitate financiară din UE. Dacă ești bancă, firmă de investiții, asigurător, instituție de plată, instituție de monedă electronică, CCP, CSD, loc de tranzacționare sau furnizor critic de ICT pentru oricare dintre acestea, ești în scop.
Textul e dens, iar RTS-urile/ITS-urile suport sunt și mai dense. Acest articol e un ghid de teren pentru liderul ICT și de securitate, nu pentru consilierul juridic. Presupunem că ai citit DORA cel puțin o dată. Ne concentrăm pe ce se schimbă operațional și ce va sonda prima ta evaluare ESMA / EBA / EIOPA.
Ce s-a schimbat efectiv la ianuarie 2025
Trei mutări substantive în modelul de operare al securității:
- Riscul ICT a devenit subiect de decizie la nivel de board, cu review documentat cel puțin anual. Cadrul DORA de management al riscului nu e opțional și nu e fișierul CISO-ului; trebuie aprobat de organul de conducere.
- Testarea de reziliență a evoluat de la „rulăm pentest-uri” la un program structurat. Entitățile semnificative trebuie să facă TLPT (threat-led penetration testing) cel puțin o dată la trei ani, cu scop și scenarii aprobate de regulator.
- Raportarea incidentelor s-a consolidat. Fragmentarea anterioară de template-uri EBA / ESMA / EIOPA se prăbușește în procesul DORA Articolul 17, cu praguri de clasificare și termen comun.
Articolul 9 — cadrul de management al riscului ICT, în practică
Articolul 9 cere „un cadru solid, comprehensiv și bine documentat de management al riscului ICT”. În practică, regulatorul sondează:
- Un cadru documentat aprobat explicit de organul de conducere, cu un calendar de review.
- Un inventar de active ICT legat de procese de business, cu scoring de criticitate. Metodologia de scoring trebuie documentată; „esențial / important / non-critic” fără raționament e respins.
- Identificare continuă a riscurilor ICT, cu planuri documentate de tratament al riscului și acceptare a riscului rezidual.
- Capacitate de detecție testată cel puțin anual, cu metrici documentate (MTTD, MTTR, rata fals-pozitivelor).
- Măsuri de protecție și prevenție proporționale cu profilul de risc, documentate și revizuite.
- Obiective de recuperare — RTO și RPO — documentate per serviciu critic, testate cel puțin anual.
Cel mai mare gap pe care îl vedem în inspecțiile timpurii DORA: un registru de risc ICT care nu e legat de catalogul de procese de business. Această legătură face prioritizarea defensabilă.
TLPT — testul care îi neliniștește pe toți
Threat-Led Penetration Testing e obligația DORA Articolul 25 cu cea mai multă conversație de hol. Substanța:
- Obligatoriu pentru entități financiare „semnificative” — pragul e setat în RTS și e în esență „ești sistemic pentru sistemul financiar UE” sau operezi într-un cluster critic.
- Rulat cel puțin o dată la trei ani, cu scop setat împreună cu regulatorul și bazat pe o fază de targeting informată de threat intelligence.
- Metodologie aliniată cu cadrul TIBER-EU al Băncii Centrale Europene. Dacă ai rulat un angajament TIBER, ai rulat un TLPT.
- Condus de testeri externi aprobați de regulator, cu un furnizor independent de threat intelligence pentru faza de targeting.
- Rezultatele se depun la regulator, cu un plan de remediere și termene.
Un TLPT nu e un red team turbo. E un exercițiu de reglementare care se întâmplă să fie un red team. Livrabilele, interfața cu regulatorul și așteptările de documentație sunt diferite față de exercițiul pe care echipa de securitate l-a cumpărat ani la rând.
Articolul 17 raportare incidente — noul proces comun
Raportarea incidentelor majore ICT se consolidează într-un singur proces Articolul 17. Pragurile de clasificare contează:
- Numărul de clienți afectați.
- Numărul de tranzacții afectate, în volum și în valoare.
- Impact reputațional.
- Durata disrupției.
- Răspândire geografică (activarea cross-border declanșează notificare regulator-către-regulator).
- Pierderi de date (legătura cu obligațiile GDPR Articolul 33).
Trebuie să documentezi logica de clasificare în politica IR. Regulatorul o va citi și va sonda dacă pragurile au fost aplicate consistent în incidentele recente.
Articolul 28 — risc terț
Articolul 28 face entitatea financiară responsabilă pentru securitatea terților ICT critici. Două schimbări operaționale:
- Un registru al aranjamentelor contractuale cu toți terții ICT, cu cei critici marcați. Registrul se furnizează regulatorului la cerere.
- Due diligence pre-contract și evaluare continuă a furnizorilor critici — obligațiile nu pot fi achitate prin acceptarea raportului SOC 2 Type II al furnizorului.
Ce va privi prima evaluare
Pentru entitățile pe care le-am sprijinit prin prima evaluare era-DORA:
- Documentul de cadru DORA, semnat de organul de conducere.
- Legătura între active și procese de business; registrul de risc care decurge.
- Acordul de scop TLPT și raportul testului (dacă e programat).
- Un sample de incidente din ultimele 12 luni și aplicarea pragurilor Articolul 17.
- Registrul terților și evaluarea cea mai recentă a top-trei furnizori critici.
- KPI: MTTD, MTTR, RTO/RPO realizat vs. țintă, respectarea SLA de remediere a vulnerabilităților.
Unde se potrivește Sandline
Rulăm exerciții TLPT cu metodologie aliniată TIBER-EU, programe de vulnerabilități care produc probă Articolul 9 și retainer-uri IR conectate la template-urile Articolul 17. Nu suntem casa ta de avocatură și nu îți scriem documentul de cadru DORA; executăm munca tehnică și producem pachetul de probă pe care vrea să îl vadă regulatorul.