DORA es llegeix com una llei. El que audita és la teva arquitectura.
Des del 17 de gener de 2025, la UE qualifica el software financer com ho faria un SRE: no pas per si falla, sinó per com es comporta mentre falla. El reglament és DORA — el Reglament de Resiliència Operativa Digital, Reglament (UE) 2022/2554 — i, un any i mig després, encara trobo equips d'enginyeria fintech que el tracten com un document que és cosa del seu departament legal i del qual ja els informaran quan toqui.
Primer de tot, una col·lisió de noms que els cercadors no resoldran per tu: aquest DORA no és DevOps Research and Assessment. Si venies buscant freqüència de desplegament i lead time, la meva crítica d'Accelerate cobreix aquelles quatre mètriques; aquest DORA ve amb supervisors incorporats.
També convé dir què soc i què no soc. No soc advocat, i res d'això és assessorament jurídic. Porto dues dècades en operacions enterprise, anys d'ells en sales de crisi a escala Clarivate, i DORA és la primera peça de regulació financera que llegeixo que sembla escrita per algú a qui els avisos han despertat a les 3 de la matinada. Des d'aquí escric aquest post: des del costat de l'enginyer que ha de construir sota les regles i les llegeix com si fossin una especificació.
El reglament assumeix que el teu sistema fallarà — i el que puntua és la resposta
DORA s'aguanta sobre cinc pilars: un marc de gestió del risc TIC (articles 5–16), classificació i notificació d'incidents (17–23), proves de resiliència (24–27), risc de tercers TIC (28–30) i intercanvi d'informació. Si li treus la bastida jurídica, el capítol II és un manual de SRE: identificar, protegir, detectar, respondre, recuperar, aprendre. La premissa que sosté els cinc pilars és la que la gent d'operacions va interioritzar fa anys: la fallada és una propietat del sistema, no una anomalia. El que hi afegeix el reglament és que la teva resposta a la fallada ara ha de ser llegible des de fora: documentada, cronometrada i reproduïble quan te la demanin.
Tot el canvi és en aquesta paraula: llegible. La majoria d'equips d'enginyeria ja fan alguna versió d'aquesta feina. Pocs la poden demostrar al ritme que marca el calendari d'un supervisor.
Un rellotge de 4 hores és un requisit d'observabilitat disfressat d'article
La notificació d'un incident greu es regeix per tres rellotges: una notificació inicial dins de les 4 hores següents a classificar l'incident com a greu (i mai més tard de 24 hores des de la detecció), un informe intermedi a les 72 hores i un informe final en el termini d'un mes.
Llegeix-ho com a enginyer i la dependència salta a la vista: no pots classificar un incident en hores si la classificació és un judici que es pren en una reunió. Els criteris de classificació de DORA — clients i contraparts afectats, durada i caiguda del servei, abast geogràfic, pèrdua de dades, criticitat dels serveis — s'han de poder calcular, cosa que vol dir que la teva monitorització ja sap quants clients toca una caiguda i que el teu tooling d'incidents pot produir aquest número amb l'incident encara obert. Un full de càlcul i una revisió els dimarts no aguanten un rellotge de 4 hores. La instrumentació, sí.
Hi ha una subtilesa que mereix enginyeria pròpia: el rellotge de 4 hores arrenca a la classificació, no a la detecció. Un procés de classificació difús no et fa guanyar temps — només trasllada el risc a una discussió amb el supervisor sobre quan hauries d'haver classificat. Els equips que ho tenen resolt tracten els llindars de severitat com llindars d'alerta: definits per endavant, avaluats per màquines i escalats a humans per confirmar, no per debatre.
I l'informe va a la teva autoritat nacional competent amb la seva plantilla, no a una bústia en prosa. Sona trivial fins que has intentat omplir una plantilla regulatòria estructurada a l'hora tres d'una caiguda, amb les persones que saben les respostes ocupades arreglant la caiguda. La solució és la mateixa que fem servir per a les status pages: el registre de l'incident és la font de dades de l'informe, i la presentació la porta algú que no és a la sala de crisi. Decidir això durant l'incident és la manera de perdre una hora de les quatre que et donen.
Algú atacarà el teu sistema de producció, amb permís
El tercer pilar inclou les proves de penetració guiades per amenaces (TLPT) per a les entitats que superen el llindar: un red team, alineat amb el marc TIBER-EU, atacant producció en viu, aproximadament cada tres anys.
Aquí s'acaba la cultura del pentest només-a-staging. Quan l'objectiu del test és producció, cada ficció còmoda passa a poder-se comprovar: la segmentació de xarxa que existeix al diagrama, el compte break-glass que ningú no ha rotat, la regla de detecció que salta a staging perquè allà gairebé no hi ha soroll de fons. He vist incidents de producció destapar totes tres; el que fa el TLPT és avançar aquest descobriment a un moment que encara et pots permetre.
La teva llista de proveïdors s'ha convertit en un artefacte regulat
El pilar amb més conseqüències quotidianes per a com construeixes és el risc de tercers. Cada acord TIC entra en un registre d'informació: quina funció suporta, com de crítica és aquesta funció, si el proveïdor és substituïble i a qui subcontracten ells. Aquest últim camp és el que sorprèn els equips d'enginyeria — el registre vol la cadena, no la primera baula. La teva base de dades gestionada corre sobre un hyperscaler; la teva API de scoring de frau crida un proveïdor de models; el registre espera que ho sàpigues, i els supervisors recullen aquests registres de les entitats financeres des del 2025. A la pràctica és un graf de dependències — el mateix artefacte que construiries per revisar la disponibilitat a fons, i aquesta és la idea. Els contractes amb proveïdors crítics han d'incloure drets d'auditoria, nivells de servei, assistència a la terminació i una estratègia de sortida provada (article 28). Els supervisors poden fer, i fan, la pregunta de concentració: què et passa si aquesta regió cloud, o aquest proveïdor, té un mal dia? La caiguda de CrowdStrike del juliol de 2024 — 8,5 milions de sistemes fora de servei per l'actualització d'un sol proveïdor — és el cas pràctic que els reguladors ja no han d'imaginar.
Aquí és també on apareix un partner d'enginyeria extern, i declaro l'interès sense embuts: Conectia encasta enginyers en clients regulats, així que som una entrada en registres com aquests. Un engagement amb una fintech ha d'encaixar amb aquest pilar des del primer dia — qui té quin accés, sota quin contracte i què produeix la sortida. És part del perquè els nostres engagements acaben amb un handover documentat i un esborrat segur: cada credencial, bústia i accés a repositori comptabilitzat i tancat. En un context DORA això no és cortesia. És l'evidència a què apunta el teu registre quan algú audita la sortida.
El contraargument honest: complir no és ser resilient
Ara la concessió, perquè és real: pots complir DORA sobre el paper i continuar sent fràgil. Un registre pot estar complet i desactualitzat. Un pla de sortida provat pot haver-se provat contra l'arquitectura de l'any passat. La proporcionalitat (article 4) implica que una fintech de 20 persones no correrà exercicis TIBER-EU, i l'incident que et tombi pot arribar igualment a través d'un proveïdor que compleix — entre les víctimes de CrowdStrike hi havia institucions amb la paperassa impecable.
Per què el defenso, doncs? Perquè DORA fa que la feina de resiliència sigui finançable. Tots els enginyers d'operacions hem perdut la discussió de pressupost per l'observabilitat, per una segona regió, per l'auditoria de desaprovisionament — feina que no porta cap feature associada. DORA t'estalvia aquesta discussió: el consell que no finançava el tooling d'incidents com a higiene d'enginyeria el finançarà com a termini regulatori, i la feina és idèntica. Aprofita el pressupost.
Què faria aquest trimestre si dirigís enginyeria en una fintech
- Connecta els criteris de classificació a la monitorització. Clients afectats, downtime, pèrdua de dades: camps calculats al registre de l'incident, no prosa escrita després.
- Fes un simulacre de notificació. Agafa un sev-1 passat, reprodueix-lo contra els rellotges de 4h / 72h / 1 mes amb la plantilla real de reporting i cronometra cada pas. Els forats que trobis són el teu backlog.
- Construeix el registre com a dades, no com a document. Un inventari de proveïdors en control de versions, amb camps de responsable, criticitat i subcontractistes, revisat amb cadència — el registre desactualitzat és el mode de fallada.
- Demana a cada proveïdor crític que t'expliqui la seva sortida, pas a pas. I executa'n una de debò: restaura el backup, exporta les dades, reconstrueix el pipeline. Una estratègia de sortida que no s'ha executat mai és una hipòtesi.
- Fes que l'offboarding produeixi evidència. Cada sortida — empleat o extern — s'hauria de tancar amb una checklist d'accessos que algú signa. És als finals on moren els audit trails.
Divuit mesos després de DORA, els equips que pateixen són sobretot els que encara el tradueixen de legal a enginyeria, memoràndum a memoràndum. Llegeix-lo tu mateix, un cop, amb ulls d'operador. Es llegeix com una llei. El que audita és la teva arquitectura.
Si tens per davant feina de resiliència amb terminis regulatoris i vols enginyers que ja han operat sota auditoria, parla amb un CTO.
