A la lliçó anterior, en analitzar la bretxa de la consultora i en respondre a la del proveïdor de correu, vas necessitar dues vegades una cosa que Nimbus encara no té: un quadern de bitàcola, un equip amb rols, una decisió sobre a qui es comunica i en quin termini, i una seqüència acordada per endavant. Torna un moment a la taula de les primeres 72 hores de 02-06: dia 20, 09:00, la Marta convoca l'equip i ningú no sap què fer primer. Desconnectar? Avisar els clients? Trucar a qui? Aquest buit no l'omple ni el millor registre de riscos ni el catàleg de controls més complet. L'omple un document escrit abans, assajat i accessible quan tota la resta està xifrada. Aquesta lliçó és aquest document: l'equip, la matriu de severitat, la preservació d'evidències, les disjuntives reals de la contenció, les plantilles de comunicació, els runbooks i el post mortem.

1. Per què el pla s'escriu abans: esdeveniment, incident i crisi
2. El cicle de resposta del NIST SP 800-61
3. Preparació: el 80 % del resultat
4. Classificació i severitat
5. Detecció i anàlisi, i la preservació d'evidències
6. Contenció: les disjuntives reals
7. Eradicació i recuperació
8. Comunicació: la meitat de la feina
9. El quadern de bitàcola
10. Runbooks per escenari
11. El post mortem sense culpables
12. Exercicis de taula

A les tres de la matinada, amb l'agenda de 40 clíniques aturada i un telèfon que no para de sonar, ningú no improvisa bé. La capacitat de raonar amb calma s'esfondra justament quan més falta fa, i les decisions d'aquells primers minuts —apagar un servidor, esborrar un fitxer sospitós, contestar un periodista— condicionen tota la resta, inclosa la possibilitat de saber després què va passar. El pla no serveix per tenir respostes genials: serveix perquè les decisions importants ja estiguin preses quan arribi el moment d'executar-les.

La diferència entre incident i crisi no és de mida tècnica, és de qui ha de ser a la sala. Un incident el gestiona l'equip tècnic amb un responsable; una crisi exigeix la direcció, probablement assessoria jurídica i comunicació, i decisions que no són tècniques —notificar, pagar o no pagar, parlar o no parlar públicament—. Escalar tard d'incident a crisi és una de les fallades més cares i més freqüents.

Dues observacions sobre el diagrama. La primera: la preparació és el 80 % del resultat. Tot el que es pot fer en fred —decidir qui mana, tenir els telèfons, saber on són els registres, haver provat una restauració— multiplica l'eficàcia de les altres tres fases; el que no estigui fet abans, no s'improvisarà durant. La segona: la fletxa de tornada de contenció a detecció no és decorativa. En un incident real es descobreixen coses noves constantment —un segon servidor compromès, un compte més—, i cada troballa obliga a reavaluar l'abast. Un equip que dona per tancada l'anàlisi massa aviat conté la meitat del problema i deixa l'atacant a dins.

Quatre funcions, sempre amb suplent, perquè l'incident passarà a l'agost:

Tres regles de l'equip. Qui executa no decideix: la Lucía no ha d'estar valorant si s'avisa els clients mentre aïlla un servidor; separar les dues funcions evita l'error clàssic que la persona més ocupada prengui les decisions més importants. Una sola veu cap enfora: si tres persones responen als clients, hi haurà tres versions i una serà errònia. I el documentador no fa res més: sembla un luxe en una empresa de 38 persones, però sense ell ningú no recordarà al cap de 48 hores què es va fer a les 04:12.

El pla no pot viure només al sistema que pot estar xifrat. A 02-06 l'atacant va arribar al compte al núvol, als buckets i a les còpies; si el pla, els telèfons i els runbooks haguessin estat únicament a la suite ofimàtica corporativa, l'equip s'hauria quedat sense pla justament quan el necessitava.

Nimbus no té capacitat forense pròpia i no ha de fingir que la té. El que sí que pot tenir, i costa poc, és un acord de retenció signat abans amb un proveïdor forense: negociar preu i condicions el dia de l'incident és lent i car. El mateix amb l'assessoria jurídica i amb el contacte de l'asseguradora, el telèfon del qual ha de ser a la targeta impresa perquè, com vas veure a 04-01, moltes pòlisses obliguen a notificar en un termini curt i a fer servir els seus propis pèrits. Quant a preparació tècnica, el mínim viable: registres centralitzats fora de les màquines que registren, amb retenció de 90 dies en calent i un any en fred; un usuari de només lectura per investigar sense modificar; una màquina neta d'anàlisi; i les credencials break-glass provades almenys una vegada l'any. I la formació mínima: que tot l'equip sàpiga dues coses —com es declara un incident i a qui es truca— i que la Lucía i l'Iván hagin executat almenys un runbook en un exercici de taula.

Tres regles de classificació que eviten discussions inútils. Davant el dubte, s'escala: baixar la severitat després costa un correu, pujar-la tard costa dies de permanència de l'atacant, i ningú no serà renyat per haver declarat un S2 que va resultar ser un S3. La severitat es revisa contínuament: l'incident de 02-06 va començar com «una incidència de rendiment» que el Rubén atenia com a S4, i la severitat d'entrada gairebé mai no és la definitiva. I la incertesa sobre l'abast puja la severitat, no la baixa: «no sabem si van sortir dades» es tracta com a S1 fins a demostrar el contrari, precisament perquè no poder determinar l'abast va ser el problema central del dia 22 a 02-06.

Cinc fonts, ordenades de millor a pitjor. L'alerta pròpia és la ideal i la que Nimbus gairebé no té (04-03). Un empleat avisa sovint, i amb quina rapidesa depèn completament que reportar no es castigui (POL-04 5.3.1). Un client, que va ser la via de detecció a 02-06, vint dies tard. Un avís extern d'un investigador, del CERT nacional o d'un proveïdor. I el mateix atacant, amb la nota de rescat o el correu d'extorsió: la pitjor manera possible d'assabentar-se'n.

La disciplina més valuosa de les primeres hores és separar fets d'hipòtesis al quadern de bitàcola, explícitament, perquè en un incident real les suposicions es converteixen en fets per repetició: algú diu «sembla que van entrar per la VPN», mitja hora després és «van entrar per la VPN» i dues hores després s'està reconstruint la VPN mentre l'atacant continua a dins per un altre lloc.

Tota acció de contenció destrueix informació: apagar una màquina esborra la memòria, reiniciar un contenidor elimina el sistema de fitxers efímer i rotar una credencial impedeix veure què més feia. D'aquí la regla —capturar primer, actuar després— seguint l'ordre de volatilitat, en què el que abans desapareix es recull abans.

Quatre decisions de l'script que són de mètode, no de programació. No apaga la màquina, perquè apagar-la destrueix l'evidència més valuosa i, amb alguns ransomware, pot empitjorar l'estat del xifratge. Recull en un volum extern, no al disc compromès, per no sobreescriure espai no assignat. Calcula hashos, perquè una evidència sense integritat verificable és discutible davant una asseguradora o un tribunal. I documenta la cadena de custòdia: qui la va recollir, quan, amb quin mètode i on és. Quan aturar-se i trucar un forense: atura qualsevol manipulació addicional i truca el retenidor si: hi ha indicis d'exfiltració de dades personals; l'atacant ha tingut accés administratiu; hi ha ransomware; l'incident pot acabar en reclamació judicial, denúncia o part a l'asseguradora; o simplement no saps què estàs mirant. L'instint de «investigaré una mica més» és comprensible i és exactament el que destrueix les evidències que després fan falta per determinar l'abast —i sense abast no es pot notificar amb precisió, que va ser l'atzucac del dia 22 a 02-06—.

La contenció busca aturar el dany sense destruir la informació que fa falta per entendre l'abast, i es divideix en dues: la contenció a curt termini, amb mesures immediates per aturar l'hemorràgia —aïllar la màquina de la xarxa mantenint-la encesa, bloquejar una IP, deshabilitar un compte, tallar una integració—, i la contenció a llarg termini, que permet continuar operant mentre s'eradica: aixecar un entorn net en paral·lel, afegir regles de filtratge, restringir funcionalitat no essencial. Les tres disjuntives que cal haver pensat en fred:

I el catàleg de decisions típiques de contenció a Nimbus, amb el que cal saber de cadascuna:

Eradicar és eliminar la presència de l'atacant i la causa que li va permetre entrar: tancar la vulnerabilitat, eliminar la persistència detectada al pas 4 de l'script, retirar els comptes i claus que va crear i corregir la configuració que ho va fer possible. Aquí s'aplica la regla més important de l'apartat: davant el dubte, reconstruir en lloc de netejar. Si un servidor ha tingut un atacant amb privilegis administratius, no pots demostrar que l'has netejat del tot; només pots demostrar que n'has creat un de nou. A Nimbus això és especialment barat perquè la infraestructura és contenidors i desplegament automatitzat: reconstruir des de la imatge i el codi verificats és més ràpid que auditar un sistema sospitós, i acaba amb certesa en lloc d'acabar amb esperança. Naturalment, reconstruir només serveix si no reintrodueixes la vulnerabilitat: primer s'eradica la causa, després es reconstrueix. I per tornar a producció calen cinc condicions, escrites perquè la pressió comercial no les escurci: causa arrel identificada i corregida; sense indicis de persistència; credencials potencialment exposades rotades; dades restaurades verificades (04-06); i monitoratge reforçat durant almenys dues setmanes, perquè els atacants tornen, i tornen pel mateix lloc si ningú no el va tancar.

Nota de validació. El termini de 72 hores per notificar una bretxa de dades personals a l'autoritat de control, l'obligació de comunicar-ho als afectats, la denúncia davant les forces de seguretat i les implicacions de pagar un rescat —que pot tenir conseqüències legals segons la jurisdicció, la identitat de l'atacant i la normativa de sancions internacionals— són qüestions jurídiques. Nimbus no les decideix a la sala de crisi: les consulta amb assessoria jurídica i amb el responsable de compliment des de la primera hora. El detall de les obligacions es tracta a 06-03.

Cinc regles de redacció que aquesta plantilla aplica: no prometre el que no se sap —«les seves dades són segures» sense haver-ho verificat és la frase que després destrueix la credibilitat—; dir explícitament què no se sap encara, perquè la incertesa comunicada genera més confiança que la certesa falsa; donar accions concretes al client, cosa que redueix trucades i li retorna una mica de control; comprometre una data per a la següent comunicació i complir-la encara que no hi hagi novetats; i un únic canal de contacte, perquè el suport no col·lapsi ni apareguin versions diferents.

Un registre cronològic, escrit en el moment i no reconstruït després, de tot el que s'observa i es decideix. Importa per tres raons: permet l'anàlisi posterior amb dades reals en lloc de records; sosté la defensa jurídica i la reclamació a l'asseguradora, que preguntaran quan es va saber i quan es va actuar; i evita feina duplicada quan entra gent nova a l'incident al cap de dotze hores.

L'última regla no és cortesia: la bitàcola pot acabar llegida per un advocat, un pèrit o un client, i una frase com «això va passar perquè la Lucía no revisa mai res» converteix un document tècnic en un problema afegit.

Un runbook és el procediment pas a pas per a un escenari concret, escrit perquè l'executi algú amb estrès i sense temps de pensar. Estructura mínima: escenari, indicadors d'activació, severitat inicial, rols, passos numerats per fase, criteris de tancament i errors coneguts.

L'escenari més probable a Nimbus, perquè no requereix cap vulnerabilitat tècnica.

El post mortem sense culpables (blameless) és la reunió d'anàlisi posterior l'objectiu explícit de la qual és entendre el sistema, no avaluar les persones. La seva premissa: si un error humà ha pogut causar un incident greu, el problema no és la persona, és el sistema que va permetre que un error individual tingués aquella conseqüència. Com es dirigeix, en quatre regles: es convoca entre 3 i 7 dies després, ni abans —falta informació— ni gaire després —es perd el detall—; la persona més involucrada en la fallada explica la història, sense interrupcions ni judicis; es prohibeixen les frases amb «hauria d'haver» i se substitueixen per «quina informació faltava per prendre una altra decisió»; i no hi assisteix ningú amb capacitat disciplinària sobre els participants, o no hi haurà honestedat.

(1) Per què es van xifrar les dades i les còpies? Perquè un atacant va obtenir control administratiu del compte al núvol (A-05). (2) Per què va obtenir aquest control? Perquè va trobar una credencial d'A-05 en un fitxer .env del servidor d'aplicacions. (3) Per què va arribar a aquell servidor? Perquè va entrar amb el compte compartit de la consultora, sense MFA i amb accés permanent. (4) Per què existia aquell accés permanent sense MFA? Perquè es va concedir el 2023 com a excepció operativa i ningú no ho va tornar a revisar: no hi havia caducitat, ni revisió periòdica, ni requisit contractual. (5) Per què no hi havia revisió ni requisit? Perquè no existia cap procés de gestió de risc de tercers: ni avaluació prèvia, ni clàusules, ni revisió d'accessos.

Causa arrel: absència d'un procés de gestió d'accessos de tercers amb revisió i caducitat. Fixa't en dues coses. Primera: la causa arrel no és «l'atacant» ni «la Lucía va deixar un .env»; és un procés que no existia, que és justament el que es pot arreglar. Segona: els cinc perquès produeixen una cadena, però un incident real en té diverses. Aquí n'hi ha almenys dues més que mereixen la seva pròpia anàlisi: per què es va trigar 20 dies a detectar i per què les còpies eren destruïbles. El mètode s'aplica una vegada per cada cadena, no una vegada per incident.

L'apartat d'accions correctives és l'únic que importa d'aquí a sis mesos, i per això cada acció porta propietari i data, i se segueix fins al tancament a la revisió mensual de riscos de 04-01. Un post mortem les accions del qual no es tanquen és un exercici d'escriptura: l'incident tornarà amb un altre nom.

Un exercici de taula (tabletop) és una simulació conversada: es reuneix l'equip dues hores, es planteja un escenari i es pregunta «i ara què fas?», sense tocar cap sistema. És la manera més barata de provar el pla, i sempre troba els mateixos buits: ningú no sap qui decideix, el telèfon del forense no hi és, el runbook esmenta un sistema que ja no existeix, o tothom assumeix que un altre estava avisant els clients.

Tres formats amb diferent cost i valor: el repàs del pla en reunió (30 min, cost nul, trimestral), l'exercici de taula pròpiament dit (2 h, cost molt baix, semestral) i el simulacre tècnic d'un runbook —restaurar de debò—, que ocupa mitja jornada, té cost baix-mitjà i es fa una vegada l'any (04-06).

Guió mínim per a un de dues hores: es presenta l'escenari en tres injectes successius —l'avís inicial, un gir als 30 minuts («un client ha publicat l'incident a les xarxes») i una complicació als 60 («la persona que decideix és en un avió»)—; es documenta cada decisió en una bitàcola real; i s'acaba amb la llista de buits trobats, cadascun amb propietari i data, igual que un post mortem. Si l'exercici no genera accions, no es va fer bé.

• No tenir pla, o guardar-lo només on pot estar xifrat. El dia 20 a les 09:00 ningú no sabia què fer primer. Consell: un pla d'una pàgina amb rols i telèfons val més que un manual de 60 que ningú no ha llegit, i ha d'existir en paper i al mòbil de dues persones, amb un canal d'emergència diferent del corporatiu.
• Apagar la màquina per instint, o canviar la contrasenya abans d'exportar els registres. El primer destrueix la memòria i pot empitjorar el xifratge; el segon perd el rastre i deixa viva la sessió robada. Consell: aïllar de xarxa mantenint encès, capturar abans de contenir i revocar sempre les sessions.
• Comunicar de més o de menys. Prometre que les dades són segures sense saber-ho destrueix la credibilitat; el silenci la destrueix igual. Consell: comunica el que saps, digues el que no saps i compromet la propera actualització.
• No escalar per por d'exagerar, o investigar «una mica més» abans de trucar el forense. Consell: escriu que escalar de més mai no es retreu, defineix per escrit els cinc criteris d'aturada de l'apartat 5.3 i respecta'ls.
• Post mortem amb culpables. Garanteix que el proper incident s'amagui. Consell: sense ningú amb capacitat disciplinària a la sala i amb accions sobre el sistema, no sobre persones.

Classifica cada situació en S1-S4, justifica el nivell i indica les tres primeres accions en ordre:

1. La Sara informa que va introduir les seves credencials corporatives en una pàgina que imitava el portal de nòmines. Va passar fa 20 minuts.
2. L'escaneig extern mensual detecta que el port 5432 torna a estar obert a Internet després de la migració de la setmana passada. No hi ha evidència d'accés.
3. Una clínica avisa que, en obrir la fitxa d'un pacient seu, veu el nom d'un pacient d'un altre centre.
4. El Rubén reenvia un correu de phishing genèric que va ser bloquejat pel filtre i que cap usuari no va obrir.

A les 03:40, la Lucía detecta un procés desconegut consumint CPU al servidor d'aplicacions. Actua així:

Identifica tots els errors, indica quina informació s'ha perdut irreversiblement i reescriu la seqüència correcta amb hores plausibles.

Aplica els cinc perquès a aquesta cadena de l'incident de 02-06 que no es va analitzar a l'apartat 11.1: «El dia 20, quan es va intentar restaurar, no hi havia cap còpia utilitzable». Identifica la causa arrel i redacta tres accions correctives amb el format de l'apartat 8 de la plantilla, indicant per a cadascuna el risc del registre de 04-01 amb el qual enllaça.

Exercici 1

1. Phishing amb credencials lliurades: S3, que puja a S2 segons l'abast del compte de la Sara. La Sara gestiona administració i RH, així que té accés a nòmines i dades d'empleats (A-16) i probablement a facturació: això l'empeny a S2. Primeres accions: (a) obrir bitàcola i exportar els inicis de sessió del seu compte abans de tocar res; (b) revocar totes les sessions actives, restablir la contrasenya i forçar un nou segon factor; (c) revisar regles de reenviament, delegacions i aplicacions OAuth de la seva bústia. És literalment RB-01. I una quarta acció no tècnica però obligatòria: agrair-li l'avís, perquè va avisar en 20 minuts i això és el que converteix un desastre en un incident menor.

2. PostgreSQL reexposat: S3. No hi ha evidència d'accés, però és un servei crític exposat a escaneig automatitzat permanent, així que no pot esperar l'endemà. Accions: (a) tancar el grup de seguretat immediatament —la contenció és trivial i no destrueix evidència—; (b) revisar els registres de connexió de PostgreSQL a la finestra d'exposició per descartar accessos, i si n'hi hagués, escalar a S1; (c) obrir la causa arrel: per què la migració va reintroduir la regla, que és un cas de deriva de controls de 04-03 i s'ha de corregir al procés de desplegament, no només al grup de seguretat.

3. Un client veu dades d'un altre: S1. És una fallada d'aïllament entre tenants, és a dir, una bretxa de confidencialitat de dades que revelen salut, i encara que l'origen sigui un error de programació i no un atac, l'impacte és el mateix. Accions: (a) preservar evidència: capturar la petició exacta, l'usuari, l'hora i el registre d'auditoria associat; (b) determinar l'abast —és un cas aïllat o fa mesos que veuen dades alienes?—, cosa que es fa consultant la taula d'auditoria de C-07; (c) contenir, desactivant la funcionalitat afectada si l'abast no està acotat a la primera hora, i activar en paral·lel la consulta amb assessoria pel rellotge de les 72 h. L'error típic aquí és tractar-ho com un bug de la cua de treball en lloc de com un incident de seguretat.

4. Phishing bloquejat: S4. No hi va haver impacte: es registra, es comprova si altres usuaris el van rebre i s'utilitza com a insum per a la formació (06-05), sense consumir l'equip de resposta.

Exercici 2

Errors, i el que cadascun va destruir:

Seqüència correcta:

Exercici 3

Cinc perquès. (1) Per què no hi havia còpia utilitzable? Perquè les còpies van ser esborrades per l'atacant el dia 20 a les 02:10 i l'única alternativa era un disc extern de feia cinc setmanes. (2) Per què les va poder esborrar? Perquè residien al mateix compte al núvol que producció i eren accessibles amb les mateixes credencials administratives. (3) Per què eren allà? Perquè es van configurar buscant comoditat operativa i cost, sense modelar l'escenari d'un atacant amb credencials d'administració. (4) Per què no es va detectar aquella debilitat abans? Perquè no existia avaluació de riscos ni catàleg de controls que preguntés «què passa si l'atacant té les credencials d'administració?». (5) Per què ningú no va saber que la còpia de cinc setmanes tampoc no servia? Perquè mai no s'havia provat una restauració: no se'n coneixia ni la integritat ni el temps que caldria.

Causa arrel: l'estratègia de còpies es va dissenyar contra la fallada tècnica —un disc que es trenca— i no contra l'adversari, i la seva eficàcia mai no es va verificar.

Observa que les tres accions són una de preventiva, una de verificació i una de detectiva, aplicant la regla de 04-03 de cobrir diverses funcions. I observa també que la número 2 no afegeix cap protecció nova: només comprova que la número 1 funciona. Sense ella, d'aquí a un any Nimbus tornaria a tenir còpies en què creu.

Has escrit el pla abans de l'incident, que és l'única manera que serveixi, perquè a les tres de la matinada ningú no improvisa bé i les decisions importants han d'estar preses per endavant. Distingeixes esdeveniment, alerta, incident i crisi, sabent que la diferència entre incident i crisi no és de mida tècnica sinó de qui ha de ser a la sala, i que escalar tard és una de les fallades més cares. Coneixes el cicle del NIST SP 800-61 amb les seves dues lliçons: la preparació és el 80 % del resultat i l'anàlisi es reobre cada vegada que apareix una troballa nova, perquè tancar l'abast massa aviat deixa l'atacant a dins. Tens l'equip de resposta de Nimbus amb titulars i suplents i les seves tres regles —qui executa no decideix, una sola veu cap enfora, i el documentador no fa res més—, els contactes fora de banda en paper i en un canal diferent perquè el pla no pot viure només al sistema que pot estar xifrat, el retenidor forense i el contacte legal signats en fred, i la matriu de severitat de quatre nivells amb la regla que davant el dubte s'escala i que la incertesa sobre l'abast puja la severitat. Saps fer triatge separant fets de suposicions per escrit, perquè una hipòtesi no es converteixi en certesa per repetició. I domines el que més incidents arruïna: preservar evidències abans de tocar res, amb l'ordre de volatilitat, un script de recollida que no apaga la màquina, escriu en volum extern, calcula hashos i documenta la cadena de custòdia, i els cinc criteris per aturar-se i trucar un forense. Coneixes les disjuntives reals de la contenció —aïllar ja davant observar, que tallar avisa l'atacant i pot accelerar la destrucció com el dia 20, i per què no s'apaga—, i en l'eradicació, la regla de reconstruir en lloc de netejar quan hi va haver privilegis administratius, amb les cinc condicions per tornar a producció amb monitoratge reforçat.

T'endús les plantilles: el comunicat a clients amb les seves cinc regles de redacció —no prometre el que no se sap, dir què no se sap, donar accions concretes, comprometre la següent comunicació i un únic canal—, la nota interna, el quadern de bitàcola amb les seves regles d'escriptura, el runbook complet de compromís de credencials amb els seus errors coneguts i l'esquema d'altres tres, i l'informe post mortem l'apartat d'accions correctives del qual és l'únic que importa d'aquí a sis mesos. I t'endús el mètode del post mortem sense culpables aplicat a 02-06, amb la causa arrel que no és «l'atacant» ni una persona, sinó l'absència d'un procés de gestió d'accessos de tercers amb revisió i caducitat, més el recordatori que un incident té diverses cadenes causals i cadascuna mereix la seva anàlisi. Tanquen la lliçó els exercicis de taula, la manera més barata que existeix de descobrir que el telèfon del forense no hi és i que tothom assumia que un altre avisava els clients. Però repassa l'exercici 3 i veuràs el que falta. Les tres accions correctives de la causa arrel de les còpies —immutabilitat en compte separat, prova de restauració trimestral, alerta d'esborrament— no són resposta a incidents: són una altra disciplina. El pla de resposta et diu com actuar quan l'agenda de 40 clíniques està aturada, però no quant de temps pot estar aturada abans que el negoci no ho resisteixi, ni quantes dades es pot permetre perdre, ni com continuen atenent el Rubén i les clíniques mentre el sistema no torna, ni quant triga realment una restauració que ningú no ha cronometrat.

A l'última lliçó del mòdul, Recuperació davant Desastres i Continuïtat de Negoci (04-06), respondràs a això: la diferència entre BCP i DRP, l'anàlisi d'impacte en el negoci, RTO i RPO fixats des del BIA i no des del desig, les estratègies de còpia amb la regla 3-2-1-1-0 desenvolupada dígit a dígit, la prova de restauració com a cor de la lliçó —perquè una còpia no verificada no és una còpia—, l'escenari ransomware que trenca els plans clàssics, l'alta disponibilitat que no és còpia de seguretat, l'ordre d'arrencada per dependències i els procediments manuals d'emergència.