Quatre. De més de vuit-centes. Aquest és el nombre d'intervencions en què l'empresa atacada va arribar a prop de l'objectiu de recuperació que ella mateixa tenia escrit —les clàssiques 24 o 48 hores—, segons el primer informe anual d'una firma nord-americana que es dedica a això i només a això. I cap de les més de vuit-centes, diu el mateix informe, no va recuperar la capacitat operativa completa fins diverses setmanes després. El número no diu que aquelles empreses no tinguessin còpies. Diu una cosa pitjor: que el pla estava mesurant alguna cosa que no era el que va passar.
D'on surt el número, i què no demostra
Del State of Recoverability 2026 de Fenix24, publicat el 15 de setembre del 2026. Són dades de camp, no respostes d'enquesta: més de 500 recuperacions de ransomware i 800 intervencions amb clients. La frase, traduïda, és que «només quatre es van acostar a l'objectiu de temps de recuperació de 24 a 48 hores típicament documentat per endavant» (only four came close to the 24- to 48-hour recovery time objective typically documented in advance).
La mostra està esbiaixada per definició: són empreses que van haver de trucar a un equip extern de recuperació, els pitjors dies del sector i no una radiografia del teixit empresarial. I Fenix24 ven recuperació, així que un informe on gairebé ningú no se sap recuperar li va de cara. Les dues coses empenyen el número en la mateixa direcció.
Dit això, el biaix no dona per a tant. Perquè un quatre sobre vuit-centes fos soroll estadístic caldria creure que les empreses que sí que compleixen el seu RTO documentat no necessiten mai ajuda externa, i no va així: quan et xifren la producció truques a algú encara que tinguis el pla impecable. El biaix explicaria un 30% en comptes d'un 60%. No explica un 0,5%.
Dues columnes: el que es declara i el que es troba
El mateix assumpte, mesurat per una enquesta i mesurat a camp:
Abans de restar: les dues columnes no mesuren el mateix ni pregunten a la mateixa gent. El 60% són organitzacions ja atacades explicant a un enquestador si el seu pla de crisi inclou un procediment d'Active Directory. El 99,2% són els clients que arriben a una recuperació concreta amb un equip extern al davant i la carpeta oberta. La taula és un contrast de mètode —declarat davant d'observat—, no una resta.
La temptació és llegir això com que la gent menteix a les enquestes. El que passa és que sota la mateixa pregunta —teniu un procediment de recuperació d'identitat?— hi viuen tres preguntes diferents, i només la tercera serveix d'alguna cosa: existeix un document?, és on es pot llegir quan el directori ja és de l'atacant? i l'ha executat algú de principi a fi? La primera es respon que sí amb tota la bona fe del món. Les altres dues gairebé mai no es pregunten. És el mateix mecanisme que ja ens vam trobar llegint l'informe de caigudes de l'Uptime Institute: el que falla no és l'absència de documentació, és un procediment que ningú no ha assajat.
El rellotge no comença a la còpia. Comença a la identitat
Un cinquè de les primeres 48 hores d'una intervenció típica se'n va a la capa d'identitat i a res més. Aixecar una font d'autenticació prou sana com per poder demostrar que el control torna a ser teu. Una, no el directori sencer.
Té tota la lògica del món quan ho penses en ordre. Mentre no hi ha una identitat neta no es pot autoritzar res: ni muntar un repositori de còpies, ni donar accés a un tècnic que arriba de fora, ni aprovar un canvi d'emergència, ni confiar que el compte amb què estàs restaurant sigui teu i no seu. La identitat no és un sistema més de la llista. És la peça de la qual penja el permís per fer tots els altres. I és, molt sovint, de la qual penja també el servidor de còpies: el servidor de còpies ficat al domini és la dependència circular que converteix un incident en una setmana.
Fes la resta amb el teu propi número. Si el teu RTO escrit són 24 hores i l'experiència de camp diu que un cinquè de les primeres 48 —unes nou hores i mitja, si es repartissin per igual— se'n va només en identitat, el pla no s'incompleix per lentitud del restore ni per falta d'amplada de banda. S'incompleix a la primera pàgina, abans de tocar una dada. I el mateix informe posa el terra del que ve després: reconstruir la infraestructura fins a una viabilitat mínima porta 72 hores o més.
La còpia era sencera i tot i així no va servir
La immutabilitat tampoc no tanca el problema: en el 38% de les intervencions en què les còpies van sobreviure a l'atac pràcticament intactes, les còpies no van poder sostenir la recuperació igualment. Els motius que dona són quatre: massa antigues, incompletes, del tipus equivocat, o més lentes de restaurar que reconstruir el sistema des de zero.
La quarta és la que més cou, perquè és l'única de les quatre que no es veu mirant la consola de còpies. Que restaurar sigui més lent que reinstal·lar és una dada que només coneixes si alguna vegada has cronometrat una restauració completa de debò, amb el rellotge a la mà i sobre ferro que no és l'original. Si ningú no ho ha fet, el número del pla és una estimació que no ha passat mai per un cronòmetre. Sobre d'on surt aquest número quan es calcula bé, vam escriure això a l'agost: com es calculen de debò l'RTO i l'RPO.
El pla està ben escrit i mesura el que no toca
Aquí entra el segon informe, que mira el mateix des de l'altre costat. Cohesity va publicar el 23 de setembre del 2026 el seu Global Cyber Resilience Report, fet per Vanson Bourne amb 3.200 responsables de TI i seguretat de dotze països i organitzacions de més de mil empleats, amb treball de camp al juliol del 2026. La seva troballa principal reenquadra la pregunta: el 78% orienta la recuperació a restaurar sistemes en lloc de a sostenir l'operació del negoci durant l'atac.
Són dos objectius diferents i produeixen dos plans diferents. Un ordena per sistemes i pregunta quan torna tot?; l'altre ordena per processos i pregunta què ha de seguir funcionant mentrestant? L'informe posa nom al segon: empresa mínima viable, l'acotament del que s'ha de restaurar primer perquè el negoci no s'aturi. El té documentat el 37%. Documentat i provat, el 22%.
L'escletxa entre el 37 i el 22 és la mateixa que separava les dues columnes de la taula de dalt: molt diferent en mida, idèntica en causa. Dels que el van documentar i el van provar, el 92% diu que va influir en les seves prioritats de recuperació —dada autodeclarada, amb el matís de sempre: qui ha fet l'esforç tendeix a dir que va valer la pena—.
Què és una empresa mínima viable quan sou quaranta
Les definicions dels informes estan pensades per a organitzacions de més de mil empleats, així que convé abaixar-les. En una empresa de quaranta persones, una empresa mínima viable no és una llista de servidors. És una llista de quatre o cinc processos —facturar, cobrar, lliurar el que véns, atendre el client que ja tens— i, per cadascun, tres coses: de quina font d'identitat depèn, de quina dada depèn i de quin tercer depèn.
La primera vegada que algú omple aquesta taula gairebé sempre passa el mateix: la columna d'identitat surt idèntica a les cinc files. Un únic inquilí i una única manera d'entrar. Això no està malament per si sol —és el raonable de muntar— però significa que els cinc processos tenen un sol punt de fallada compartit, i que l'ordre de recuperació no el decideixes tu: el decideix aquesta columna.
I després hi ha la part que ningú no vol escriure, que és la que de debò defineix el document: una empresa mínima viable és, sobretot, la llista del que has decidit NO recuperar primer. Per això costa tant, i per això no és un exercici tècnic: es tracta de decidir a qui li diràs que esperi, i que aquesta decisió la prengui l'amo del procés i no el tècnic que estigui de guàrdia.
L'abast creix mentre l'estàs escrivint
Un detall de l'informe de Cohesity que convé ficar al disseny des del principi: entre les organitzacions que van arribar a patir un atac amb impacte material, al 70% li va créixer el perímetre de sistemes afectats per sobre de la valoració inicial. El dia u encara no saps què està tocat. I d'aquest mateix grup, el 60% va tenir problemes d'identitat i accés després de restaurar: la mateixa història de la capa d'identitat, explicada per una mostra completament diferent.
La conseqüència pràctica és poc intuïtiva: l'ordre de recuperació no s'escriu per criticitat, s'escriu per dependència. Un pla ordenat per criticitat —el més important primer— es trenca així que el perímetre creix, perquè el més important resulta que depèn d'alguna cosa que encara no sabies que estava xifrada. Un pla ordenat per dependència aguanta, perquè cada pas només necessita que estigui fet l'anterior.
I falta l'altra meitat, que ja ho vam explicar fa una setmana amb les dades de Semperis: recuperar ràpid i fer fora l'atacant no són la mateixa tasca, i fer la primera sense la segona és signar el segon atac. L'empresa mínima viable diu què aixeques primer; no diu que puguis aixecar-ho abans de saber que la casa és teva.
Les sis línies que demanem abans de parlar d'RTO
És el que posem sobre la taula a la primera sessió, i cap en un full. No substitueix un pla de continuïtat; serveix per saber si el que tens mesura alguna cosa:
- Els quatre o cinc processos que, aturats una setmana, s'emporten l'any per davant. Amb el nom de la persona que ho afirma, no el del departament. Si en surten dotze, no has prioritzat: has fet un inventari.
- De quina font d'identitat depèn cadascun. Si la resposta és la mateixa a totes les files, aquest és el teu coll d'ampolla i el primer tram del teu rellotge.
- Per a cada procés, com es fa a mà i quants dies aguanta així. Facturar a mà aguanta uns dies; lliurar programari, no. Si un procés no té mode degradat, escriu-ho igualment: aquesta resposta és la que explica el teu RTO real.
- Quant va trigar l'última restauració completa que vas cronometrar. La cronometrada, no l'estimada, i sobre ferro diferent de l'original. Sense aquest número no hi ha RTO.
- On es llegeix el pla si el directori ja és de l'atacant. Paper, un altre inquilí, una còpia fora de banda. Un PDF al SharePoint corporatiu no compta: viu dins del que ha caigut.
- I qui autoritza un canvi d'emergència quan no es pot verificar la identitat de ningú. Cal un nom i un suplent, localitzables per un canal que no passi per la xarxa que acaba de caure.
Les sis es contesten en una sola sessió. La que més triga és la quarta, i no perquè sigui difícil de mesurar: perquè acostuma a ser la primera vegada que algú pregunta si està mesurada.
Quan això NO és el teu problema
Si sou deu persones, tot és a Microsoft 365 i teniu una aplicació de negoci, no necessiteu un programa de continuïtat. Necessiteu tres coses: una còpia que algú hagi restaurat de debò alguna vegada, el telèfon de qui la restaura, i un compte d'administració d'emergència que no depengui del flux normal d'accés. Muntar-hi un exercici formal d'empresa mínima viable és paperassa amb nom bonic, i es nota a la primera pàgina.
La cosa canvia quan hi ha producció pròpia, quan el client signa un acord de nivell de servei o quan una setmana aturat et costa el contracte de l'any. Aleshores l'exercici es paga sol. I ho diem sabent perfectament que el segon cas és el que facturem nosaltres: per això convé que quedi escrit també el cas en què no cal.
On encaixa això en el que fem
Portem còpies gestionades amb Proxmox Backup Server i Veeam, amb la filosofia 3-2-1 i còpies immutables. La part de la nostra feina que més s'assembla a aquest article és la conversa prèvia, la de decidir què ha de seguir dret. Això és compliment i continuïtat —el pla, l'abast, l'assaig i la prova que existeix—, i la seva altra meitat és disaster recovery, que és la que posa el ferro i els minuts. Si vols que mirem amb tu aquestes sis línies sobre el teu cas concret, escriu-nos. La quarta la mesurem nosaltres si cal.
Fonts. Les dades de camp (quatre de més de 800 intervencions a prop de l'objectiu de 24-48 hores, 99,2% sense pla documentat de recuperació d'identitat, un cinquè de les primeres 48 hores al pla d'identitat, 72 hores o més fins a la viabilitat mínima de la infraestructura i 38% de còpies intactes que no van poder sostenir la recuperació) són de l'informe The State of Recoverability 2026 de Fenix24, construït sobre més de 500 recuperacions de ransomware i 800 intervencions amb clients: nota de premsa del 15 de setembre del 2026 (el PDF de l'informe és a fenix24.com, però el seu servidor ens va tornar un 403 en intentar descarregar-lo el 27 d'octubre, així que només enllacem la nota). Les dades d'enquesta (78% que orienta la recuperació a restaurar sistemes, 37% amb empresa mínima viable documentada, 22% documentada i provada, 92% d'aquests que diu que va influir en les seves prioritats, 70% amb creixement del perímetre sobre la valoració inicial i 60% amb problemes d'identitat i accés després de restaurar) són del Global Cyber Resilience Report de Cohesity, publicat el 23 de setembre del 2026, fet per Vanson Bourne amb 3.200 responsables de TI i seguretat de dotze països en organitzacions de més de 1.000 empleats, treball de camp del juliol del 2026. Compte amb el denominador: el 70% i el 60% no són del total de la mostra, sinó de les organitzacions que van patir un atac amb impacte material. El 60% de procediments documentats de recuperació d'Active Directory és del Ransomware Risk Report 2026 de Semperis (1.200 professionals de nou països, tots d'organitzacions ja atacades amb èxit), que vam fer servir al post enllaçat del 20 d'octubre. Avís sobre la comparació: les tres fonts mesuren poblacions diferents —intervencions de recuperació, grans organitzacions i víctimes de ransomware— i dues de les tres són de fabricants que venen en aquest mercat; els percentatges no són directament comparables entre si i la taula de dues columnes s'ofereix com a contrast de mètode (declarat davant d'observat), no com una resta. Les nou hores i mitja del càlcul són nostres: surten d'aplicar el cinquè de 48 hores que publica Fenix24, que no dona aquesta xifra en hores. El nostre —les sis línies, el criteri d'ordenar per dependència en comptes de per criticitat i el cas en què no cal l'exercici— és la nostra manera de treballar, no una recomanació de cap dels informes citats. Foto: «EmergencyPowerGenerator.jpg» de Raysonho @ Open Grid Scheduler / Grid Engine, Wikimedia Commons, CC0 1.0, retallada per nosaltres.
Microsoft 365
ES 
CAT 
EN