Els 3+1 Pilars de DORA Explicats: Guia Pràctica amb Exemples per a Entitats Financeres
Publicat agost 2026 · Equip IgeraSolutions · 10 min de lectura
El Reglament (UE) 2022/2554 sobre Resiliència Operativa Digital (DORA) estructura les seves obligacions en tres pilars centrals de compliment obligatori —gestió del risc TIC, gestió d'incidents i testing de resiliència— més un quart pilar de risc de tercers que travessa els tres anteriors, i un cinquè bloc voluntari de compartir informació. En aquest article expliquem cadascun dels "3+1" pilars amb exemples pràctics del dia a dia d'un banc, una asseguradora o una gestora de fons a Catalunya, perquè els equips de compliance sàpiguen exactament què han de documentar i com IgeraRegTech ho facilita.
Per què "3+1" i no "5 pilars"?
Alguns resums de DORA parlen de 5 pilars separats. En aquest article agrupem els requisits en 3 pilars operatius obligatoris (gestió del risc TIC, gestió d'incidents, testing de resiliència) que qualsevol entitat financera ha d'implementar internament, més 1 pilar transversal (risc de tercers TIC) que connecta els tres anteriors amb els proveïdors externs. El bloc de compartir informació sobre ciberamenaces (arts. 45-46) és voluntari i no forma part del nucli "3+1".
Pilar 1: Gestió del risc TIC (articles 5-16)
El primer pilar exigeix que cada entitat financera disposi d'un marc de gestió del risc TIC aprovat i supervisat directament pel seu òrgan de govern (article 5). No es pot delegar aquesta responsabilitat íntegrament al departament d'IT: el consell d'administració ha d'aprovar la política, revisar-la almenys un cop l'any i assumir responsabilitat última davant el supervisor.
Exemple pràctic
Una cooperativa de crèdit catalana ha de mantenir un inventari actualitzat de tots els actius d'informació (article 8): servidors on-premise, instàncies al núvol, aplicacions de banca online, terminals de caixers automàtics i els contractes amb el proveïdor de core banking. Quan un auditor pregunta "qui és responsable de pegar la vulnerabilitat CVE-2026-XXXX al servidor de pagaments", la resposta ha de sortir de la documentació en minuts, no de reunions improvisades entre departaments.
Aquest pilar també inclou l'article 9 (protecció i prevenció: xifratge, control d'accessos, segmentació de xarxa) i l'article 11 (plans de continuïtat de negoci i recuperació davant desastres, amb objectius de temps de recuperació —RTO— i punt de recuperació —RPO— definits per a cada sistema crític).
Pilar 2: Gestió i notificació d'incidents TIC (articles 17-23)
El segon pilar obliga a classificar tot incident de ciberseguretat segons criteris de gravetat (clients afectats, durada, impacte econòmic, criticitat del servei) i, si l'incident es considera "major", a notificar-lo a l'autoritat competent —el Banc d'Espanya, la CNMV o la DGSFP, segons el tipus d'entitat— seguint un calendari estricte de tres fases.
Informe inicial
Màxim 4 hores des de la classificació de l'incident com a "major" (i màxim 24h des de la seva detecció).
Informe intermedi
Màxim 72 hores des de l'informe inicial, actualitzant l'estat i les mesures de contenció aplicades.
Informe final
Màxim 1 mes des de l'informe intermedi, amb anàlisi de causa arrel i lliçons apreses.
Exemple pràctic
Una gestora de fons detecta a les 10:00 del matí que l'aplicació de subscripcions online ha estat inaccessible durant 90 minuts per un atac DDoS. Si l'incident afecta un nombre significatiu de clients o operacions, l'equip de compliance té fins a les 14:00 (4 hores després de classificar-lo com a "major") per enviar l'informe inicial a la CNMV amb les dades bàsiques: hora de detecció, sistemes afectats, impacte estimat i mesures immediates preses.
Pilar 3: Testing de resiliència operativa digital (articles 24-27)
El tercer pilar exigeix un programa de proves periòdiques. Totes les entitats han de fer, com a mínim un cop l'any, tests bàsics: escaneigs de vulnerabilitats, anàlisi de codi font, proves de penetració i simulacres d'escenaris de continuïtat de negoci.
Les entitats considerades significatives pel seu supervisor —normalment els bancs grans, les asseguradores sistèmiques i determinades infraestructures de mercat— han de sotmetre's, a més, a proves avançades basades en amenaces (Threat-Led Penetration Testing, TLPT) cada tres anys, seguint la metodologia TIBER-EU.
Exemple pràctic
Un banc mitjà a Catalunya contracta un equip de "red team" extern per simular un atac dirigit contra el seu sistema de pagaments SEPA, replicant tàctiques reals d'actors amenaçadors identificats per la seva pròpia intel·ligència de ciberamenaces. El resultat —incloent quines defenses van fallar i quant de temps va trigar l'equip intern a detectar l'intrusió simulada— s'ha de documentar i compartir amb el supervisor.
El "+1": Gestió del risc de tercers TIC (articles 28-44)
Aquest és el pilar més extens del reglament en nombre d'articles i el que sovint sorprèn més les entitats, perquè no es limita a la pròpia organització sinó que s'estén a tota la cadena de proveïdors tecnològics: núvol, processadors de pagaments, proveïdors de dades de mercat, empreses de manteniment de programari i qualsevol tercer que doni suport a una "funció crítica o important".
Els requisits inclouen: mantenir un registre d'informació de tots els contractes amb proveïdors TIC (article 28), fer due diligence abans de contractar (avaluant concentració de risc, ubicació de les dades i capacitat de sortida del proveïdor), i incloure clàusules contractuals obligatòries —dret d'auditoria, obligacions de notificació d'incidents del propi proveïdor, plans de sortida (article 30)—.
Exemple pràctic
Una asseguradora migra el seu sistema de gestió de sinistres a un proveïdor cloud. Abans de signar, el departament de compliance ha de verificar que el contracte inclou clàusules de sortida (què passa si cal canviar de proveïdor en 90 dies), que el proveïdor notificarà qualsevol incident TIC propi que pugui afectar l'asseguradora, i que aquest proveïdor queda registrat en l'inventari de tercers crítics que es reporta al supervisor. Si el proveïdor és designat "crític" per les Autoritats Europees de Supervisió (EBA, ESMA, EIOPA), quedarà sotmès a supervisió directa de la UE (articles 31-44).
El bloc voluntari: compartir informació sobre ciberamenaces (articles 45-46)
A diferència dels tres pilars i el "+1", aquest darrer bloc no és obligatori. DORA permet —i incentiva— que les entitats financeres comparteixin indicadors de compromís, tàctiques d'atacants i intel·ligència de ciberamenaces amb altres participants del sector, dins d'acords fiables que protegeixin la informació sensible. Les entitats que hi participen de bona fe queden exemptes de responsabilitat per la informació compartida.
Com IgeraRegTech facilita el compliment dels 3+1 pilars
IgeraRegTech indexa el text complet del Reglament (UE) 2022/2554, les Normes Tècniques de Regulació (RTS) publicades per l'EBA, l'ESMA i l'EIOPA, i la documentació interna de compliance de cada entitat (polítiques, contractes amb proveïdors, registres d'incidents). Quan un responsable de compliance pregunta "quin article exigeix el pla de sortida d'un proveïdor cloud crític?", el sistema respon citant l'article exacte —en aquest cas, l'article 30— sense necessitat de rellegir el reglament sencer.
En resum
- Pilar 1 (arts. 5-16): marc de gestió del risc TIC aprovat pel consell.
- Pilar 2 (arts. 17-23): classificació i notificació d'incidents en 4h/72h/1 mes.
- Pilar 3 (arts. 24-27): testing anual bàsic + TLPT cada 3 anys per a entitats significatives.
- +1 Risc de tercers (arts. 28-44): registre, due diligence i clàusules contractuals amb proveïdors TIC.
- Bloc voluntari (arts. 45-46): compartir intel·ligència de ciberamenaces amb el sector.
Si el vostre despatx o entitat encara no ha documentat de forma centralitzada aquests quatre pilars, el primer pas pràctic és fer un inventari dels contractes amb proveïdors TIC crítics i verificar que inclouen les clàusules mínimes de l'article 30. És, en la nostra experiència, el punt on més entitats petites i mitjanes catalanes encara tenen gaps oberts.
Font: Reglament (UE) 2022/2554 (DORA). Última actualització: agost 2026 | Equip IgeraSolutions RegTech