Hi ha alguna cosa que poques vegades es diu en veu alta dins de les organitzacions: a tots ens agrada secretament que no passi res. Que no hi hagi bretxes. Que no hi hagi ransomware. Que ningú faci clic on no ho ha de fer. S’entén però és poc realista.
ISO 27001 i NIS2 parteixen d’una idea molt més madura: els incidents es produiran. La diferència no és evitar-los, sinó com reaccionem quan arriben. I, sobretot, som capaços de demostrar que reaccionem amb criteri, control i evidències a posteriori.
Pas 0. Abans de l’incident
Un dels errors més importants és pensar que la gestió d’incidents comença en el moment en què algú detecta que hi ha un problema. De fet, comença molt abans. Comença quan l’organització ha pres decisions clares sobre com actuarà el dia que aparegui aquest problema: qui rep la notificació inicial, qui l’analitza i la classifica, qui té l’autoritat per decidir els passos següents i sota quins criteris, i de quina manera es registrarà cada acció i cada evidència.
Si tot això no està definit per endavant, el primer incident seriós no serà només un incident de seguretat; serà, a més, un episodi de desordre organitzatiu. Hi haurà dubtes sobre responsabilitats, retards en la presa de decisions, missatges contradictoris i, probablement, una traçabilitat incompleta del que ha passat. I en matèria de ciberseguretat, el desordre multiplica l‟impacte.
Per això, marcs com ISO 27001 no es limiten a recomanar bones pràctiques, sinó que exigeixen l‟existència d‟un procés formal de gestió d‟incidents. I normatives com NIS2 van un pas més enllà: no només requereixen que aquest procés existeixi sobre el paper, sinó que funcioni a la pràctica i que l’organització sigui capaç de demostrar-ho amb evidències clares, registres i resultats mesurables.
Però hi ha alguna cosa més: sota NIS2, la responsabilitat no és només tècnica. L’alta direcció i, si escau, el consell d’administració, han de poder demostrar que han supervisat, entès i recolzat el sistema de gestió d’incidents. No es tracta només de tenir un procediment; es tracta d’assumir una governança real sobre com es gestiona el risc.
Pas 1. Detectar: algú ha de poder aixecar la mà
Tot sol començar amb alguna cosa petita. Un comportament estrany que no encaixa del tot, un accés fora d’horari que crida l’atenció, un sistema que respon més lent del que és habitual sense una raó aparent. Senyals febles, gairebé imperceptibles, que podrien ser una simple anomalia… o l’inici d’una cosa més gran.
La persona que ho detecta no ha de saber si és greu, ni confirmar si realment és un incident. La seva responsabilitat no és diagnosticar sinó saber on avisar. I aquest detall, que sembla menor, transforma completament la cultura de l’organització.
Quan les persones entenen que reportar no és ficar-se en problemes, sinó formar part activa del sistema de protecció, l’organització guanya resiliència. Es reduïx el temps de reacció, s’eviten silencis innecessaris i es construeix una xarxa d’alerta primerenca molt més eficaç que qualsevol eina tecnològica per si sola.
La millor manera de detectar és disposar d’un formulari públic per detectar i identificar les incidències com més aviat millor. Una bona alternativa és el mòdul Incident Manager d’ithikios.
Pas 2. Avaluar: aturar, pensar, classificar
En aquest segon pas és on comença la maduresa. No es tracta de reaccionar amb dramatisme ni de córrer sense adreça. Simplement es tracta d’aturar-se un moment i fer-se dues preguntes molt concretes: quin impacte pot tenir l’incident i amb quina urgència hem d’actuar.
Sembla obvi, però en aquest punt moltes organitzacions ensopeguen: comencen a executar accions abans d’haver classificat el que està passant. Es fa alguna cosa per inèrcia, per pressió o per por de quedar-se aturats. El problema arriba després, quan algú pregunta per què es van prendre determinades mesures, per què es va escalar, per què es va aïllar un sistema, per què es va comunicar —o no es va comunicar—. I aleshores no hi ha una resposta estructurada, només explicacions improvisades.
ISO 27001 insisteix que hi hagi un procés. NIS2 posa el focus en què hi hagi una avaluació raonada. A la pràctica, això significa que cada decisió s’ha de poder explicar amb serenitat: què se sabia en aquell moment, com es va valorar l’impacte, per què es va considerar urgent (o no) i com aquesta classificació va portar a l’acció. No com un exercici burocràtic, sinó com la base d’una resposta coherent i defensable davant d’auditors, autoritats o consell.
Pas 3. És significatiu sota NIS2? La pregunta incòmoda
Aquí entra en joc la dimensió reguladora. No tots els incidents s’han de notificar, i això és important entendre-ho. Però alguns sí. I el veritable risc no és notificar quan correspon, sinó no saber justificar per què vas decidir no fer-ho.
La Directiva NIS2 introdueix el concepte d’incident significatiu i estableix criteris concrets per determinar-lo: l’impacte financer que pot generar, l’afectació a serveis essencials, l’existència d’accessos maliciosos rellevants o la gravetat de les interrupcions provocades.
A la pràctica, la pregunta és senzilla: ha afectat —o pot afectar— la continuïtat del servei, dades sensibles, un nombre rellevant d’usuaris o tercers?
Aquests elements ajuden a objectivar la decisió, a evitar que depengui únicament de percepcions o intuïcions.
No obstant, més important que el criteri mateix és el raonament documentat que hi ha al darrere. La clau no és només concloure si alguna cosa és o no significativa, sinó poder explicar per què. Quina informació es va analitzar, quin impacte es va valorar, quins llindars es van considerar i com es va arribar a aquesta conclusió.
Fins i tot quan decideixes que un incident no és significatiu, aquesta decisió ha de quedar registrada. Perquè sota NIS2, l’absència d’evidència no implica que vas actuar correctament; implica que no ho pots demostrar. I en l’àmbit regulatori, cosa que no es pot demostrar, simplement no existeix.
Pas 4. Contenir: primer que deixi d’empitjorar
Contenir no és arreglar. És, simplement, impedir que el mal continuï creixent. De vegades vol dir aïllar un sistema compromès. O revocar credencials que podrien estar exposades. O fins i tot desconnectar temporalment un servei per tallar la propagació. Són decisions incòmodes, preses al mig de la pressió i el soroll.
I és precisament en aquest context quan resulta més fàcil oblidar una cosa essencial: registrar allò que s’està fent. La prioritat és actuar, protegir, estabilitzar. Documentar ens pot semblar secundari. Però el que no es deixa per escrit en calent, poques vegades es pot reconstruir en fred.
I, quan sigui possible, preservar evidències abans de “netejar” el sistema: logs, snapshots, correus, hashes, captures o qualsevol element que permeti reconstruir el que ha passat amb rigor.
Cada acció hauria de deixar un rastre clar: qui va prendre la decisió, en quin moment, quina mesura concreta es va aplicar i amb quin objectiu. No pas com un mecanisme defensiu ni com un exercici burocràtic, sinó com una eina de comprensió. Perquè quan tot passi, allò que permetrà aprendre —i millorar— no serà només el que es va fer, sinó la capacitat d’entendre per què es va fer.
Pas 5. Recuperar: tornar, però millor
Recuperar no vol dir tornar com més aviat millor. Significa tornar amb criteri. No es tracta només de restablir sistemes i reprendre operacions, sinó de fer-ho havent corregit allò que va permetre que l’incident passés.
Si hi havia una vulnerabilitat, cal corregir-ho abans de reactivar completament l’entorn. Si hi ha hagut credencials compromeses, s’han de rotar i revisar els mecanismes d’autenticació. Si es va evidenciar una debilitat estructural, cal reforçar-la. En cas contrari, el que anomenem “recuperació” no és res més que una pausa abans del següent incident.
Aquí apareix una paradoxa freqüent: moltes organitzacions gestionen raonablement bé la urgència, però descuiden l’aprenentatge. Se centren a apagar el foc i celebren quan tot torna a funcionar, però no dediquen el mateix rigor a analitzar què va fallar, quins senyals es van ignorar o quines decisions es podrien haver pres millor.
ISO 27001 insisteix en la necessitat d’extreure lliçons apreses per una raó molt simple: els incidents tendeixen a repetir-se. Canvien els detalls, però no sempre les causes profundes. Si no converteixes cada incident en un input estructurat per al teu sistema de millora contínua, el següent no només arribarà, sinó que probablement serà més costós i més difícil de justificar davant de la direcció o l’autoritat.
Pas 6. Notificar (si s’aplica): quan l’incident ja no és només teu
Hi ha un moment en què l’incident deixa de ser un assumpte exclusivament intern. Sota la directiva NIS2, s’han de notificar determinats incidents a l’autoritat competent dins de terminis concrets. I aquest requisit canvia completament la conversa.
A partir d’aquí, ja no n’hi ha prou d’haver contingut tècnicament la situació. Comença a importar com vas classificar l’incident, en quin moment vas considerar que tenies coneixement raonable del seu abast, quines mesures vas adoptar des d’aquell instant i com vas avaluar l’impacte real o potencial. La narrativa tècnica esdevé també una narrativa de gestió i de responsabilitat.
I ací la direcció ja no pot ser espectadora. Ha d’estar en condicions de donar suport a la decisió de notificar –o de no fer-ho– amb criteris clars i documentats. Perquè les conseqüències no són només tècniques; poden ser reguladores, reputacionals o econòmiques.
Fins i tot si decidiu no notificar, l’exigència és la mateixa: has de poder justificar aquesta decisió amb la mateixa solvència. Quins criteris vas aplicar, quina informació vas analitzar i per què vas concloure que no aconseguia el llindar de notificació.
És en aquest punt on es posa veritablement a prova la governança.
Pas 7. Tancar formalment: que no desaparegui en silenci
Quan tot sembla haver tornat a la normalitat, la temptació natural és girar full i seguir endavant. Però aquí és on moltes organitzacions fallen. Podríem dir que un incident que no es tanca formalment és, en realitat, un incident no acabat.
El tancament no és un tràmit administratiu; és un exercici de rigor. Implica analitzar-ne la causa arrel i no conformar-se amb els símptomes visibles. Suposa deixar constància de quines decisions es van prendre i per què, quant de temps es va trigar a detectar, contenir i recuperar, quines accions correctives es van definir i quines millores concretes es van implementar per reduir la probabilitat de repetició.
I, sobretot, aquest tancament ha d’alimentar el sistema. S’ha de traduir en ajustaments reals en procediments, controls, formació o tecnologies. Si l’experiència no modifica res, aleshores no hi va haver aprenentatge, només resolució.
En conclusió: no es tracta d’evitar incidents
ISO/IEC 27001 i NIS2 no exigeixen sistemes perfectes. Exigeixen organitzacions responsables. Organitzacions que assumeixen que els incidents no són una anomalia improbable sinó una possibilitat real. Que es preparen abans que passin. Que, quan succeeixen, actuen amb mètode en comptes d’improvisació. I que, passat el temps, poden explicar amb serenitat què va passar, com van respondre i què van aprendre.
Gestionar bé un incident no vol dir fer-lo invisible ni minimitzar-lo fins que sembli irrellevant. Significa fer-ho comprensible per a qui ho hagi d’analitzar després. Significa que sigui traçable a cada decisió ia cada acció. I, sobretot, que sigui útil per enfortir el sistema a futur.
I vol dir que cada incident es converteixi en un pla de millora: accions concretes, responsables, terminis i seguiment.
La diferència entre una organització vulnerable i una organització madura no és la manca d’incidents. És la qualitat de les seves decisions quan ningú no té totes les respostes.
Quan això passa, l’incident deixa de ser només un problema superat. Es converteix en una cosa més valuosa: una confirmació que el sistema de gestió no és decoratiu, sinó que funciona a la pràctica, fins i tot sota pressió.
