6 coses que tot pla de resposta a incidents necessita

Era un dimarts al matí de març quan una empresa de logística amb seu a Rotterdam va descobrir que els seus sistemes d’arxius estaven xifrats. Al migdia, dotze empleats estaven inactius. L’endemà al matí, tres enviaments de clients clau s’havien endarrerit. Tres setmanes més tard, havien pagat 80.000 € a un proveïdor de recuperació per restaurar l’accés parcial a les seves dades, i encara estaven explicant la bretxa a un client important que estava reconsiderant la relació.

En cap moment a l’empresa li va faltar gent competent. El que els faltava era un pla.

Aquesta història és més comuna del que la majoria dels empresaris holandesos esperarien. El 2025, més de 2.100 organitzacions holandeses es van veure afectades per ransomware, un augment del 31% respecte a l’any anterior (Searchlab Cybersecurity Statistics Netherlands, 2026). El temps d’inactivitat mitjà després d’un atac d’aquest tipus és de 23 dies. I, tanmateix, la investigació mostra consistentment que una proporció significativa d’empreses holandeses de MKB no tenen cap pla de resposta a incidents documentat, o en tenen un que mai s’ha provat.

Això va canviar significativament el 15 d’abril de 2026, quan el Parlament neerlandès va aprovar la Cyberbeveiligingswet, la implementació als Països Baixos de la Directiva NIS2 de la UE. La llei introdueix la notificació obligatòria d’incidents en un termini de 24 hores, requisits de gestió de riscos de ciberseguretat i la responsabilitat a nivell de director per a la governança de la seguretat. Per a les organitzacions dins de l’àmbit d’aplicació, un pla de resposta a incidents ja no és opcional. Per a aquelles que no hi són directament, els qüestionaris dels proveïdors dels clients més grans el converteixen en un requisit pràctic independentment.

A continuació es mostren les sis coses que necessita tot pla de resposta a incidents, escrites per a gestors de TI i propietaris d’empreses que volen un document que realment funcioni sota pressió, no només un que estigui en una carpeta.

Quan es produeix una interrupció, el primer que falla no sol ser la resposta tècnica, sinó la humana. En absència de rols definits, les persones capaces dupliquen l’esforç en algunes àrees i perden tasques crítiques en d’altres. El temps que s’hauria de dedicar a la contenció es destina a esbrinar qui ha de fer què.

El vostre pla de resposta a incidents ha de respondre tres preguntes abans que es produeixi un incident, no durant:

• Qui té l’autoritat de presa de decisions durant un incident de seguretat?
• Qui gestiona la comunicació interna i a qui informa cada membre de l’equip?
• Qui és el punt de contacte designat per a les parts externes: el vostre proveïdor de TI, l’assessor legal, l’asseguradora cibernètica i, segons NIS2, l’NCSC?

Un pla ben estructurat anomena persones específiques, no només càrrecs. També anomena còpies de seguretat, perquè els incidents rarament es produeixen quan el contacte principal està convenientment disponible. Cada persona anomenada hauria de tenir una còpia impresa o fora de línia de les seves responsabilitats, perquè els incidents sovint afecten els sistemes que d’altra manera utilitzaríeu per cercar aquesta informació.

Enmig d’un incident actiu, l’última cosa que hauria de fer el vostre equip és buscar en els fils de correu electrònic el número de telèfon d’un proveïdor o intentar recordar en quin compte s’ha presentat la pòlissa d’assegurança cibernètica. Els petits retards s’agreugen ràpidament. Cada minut dedicat a localitzar un contacte és un minut que no es dedica a la contenció.

El vostre pla de resposta a incidents hauria d’incloure, en una sola ubicació que no depengui de la disponibilitat dels vostres sistemes principals:

• Lideratge intern: persones designades amb números de mòbil, no extensions d’oficina
• El vostre proveïdor de serveis gestionats de TI o responsable de TI intern: amb un contacte fora d’hores
• Proveïdors clau de programari i infraestructura, especialment proveïdors de núvol, ERP i sistemes de còpia de seguretat
• Proveïdor d’assegurances cibernètiques: número de pòlissa, contacte de reclamacions i si requereixen la notificació d’incidents dins d’un termini específic
• Assessor legal amb experiència en violacions de dades
• La notificació d’incidents de ciberseguretat del NCSC (si sou una entitat essencial segons la Cyberbeveiligingswet)
• Socis comercials o clients clau que puguin necessitar notificació

Guardeu una versió impresa física d’aquesta llista de contactes, emmagatzemada de forma segura fora de les nostres instal·lacions o amb una persona de confiança externa a l’empresa. Un atac de ransomware que xifra els vostres sistemes de fitxers també xifra qualsevol llista de contactes que hi estiguin emmagatzemada. Moltes empreses neerlandeses ho van aprendre per les males.

Una suposició habitual en la planificació d’incidents és que les eines de comunicació romandran disponibles. Sovint no ho seran. El correu electrònic pot no estar disponible si el vostre entorn d’Exchange o Microsoft 365 es veu afectat. Les eines de missatgeria interna poden estar inactives. El vostre sistema VoIP pot ser inaccessible.

El vostre pla ha de definir canals de comunicació que funcionin independentment dels sistemes que es puguin veure compromesos, i establir expectatives sobre què es comunica, a qui i quan.

• Definiu un canal de reserva: un grup de WhatsApp compartit per al personal clau, un arbre telefònic preestablert o un punt de trobada designat per a l’equip principal.
• Definiu qui notifica al personal i què diuen. Els missatges interns poc clars durant un incident creen rumors i ansietat que fan que la situació sigui més difícil de gestionar.

• Comunicació amb el client: quan reben notificacions als clients i què se’ls diu? Un missatge d’espera enviat ràpidament gairebé sempre és millor que el silenci.
• Comunicació normativa: segons l’AVG (RGPD), una violació de dades personals s’ha de notificar a l’Autoriteit Persoonsgegevens en un termini de 72 hores des del descobriment. Segons la Cyberbeveiligingswet, les entitats essencials han de notificar a l’NCSC els incidents significatius en un termini de 24 hores. Tots dos rellotges comencen immediatament.
• Comunicació amb els mitjans de comunicació i el públic: en la majoria dels casos, no es diu res públicament fins que l’equip legal i el lideratge s’hagin alineat sobre el missatge. Definiu qui està autoritzat a parlar externament.

No tots els sistemes tenen el mateix pes. Una interrupció que afecta el programari intern de recursos humans és un inconvenient. Una interrupció que afecta el processament de pagaments, el portal d’atenció al client o la base de dades operativa principal té conseqüències financeres i de reputació immediates.

El vostre pla de resposta a incidents ha d’incloure un mapa documentat de:

• Quins sistemes són essencials per a les vostres operacions comercials principals
• Quin és el temps d’inactivitat acceptable per a cadascun (el vostre objectiu de temps de recuperació o RTO)
• Quina pèrdua de dades és tolerable: quant de temps enrere podeu restaurar i quin és el cost de restaurar versus perdre aquestes dades (el vostre objectiu de punt de recuperació o RPO)
• L’ordre de prioritat per a la restauració si diversos sistemes es veuen afectats simultàniament

Aquesta és la secció de la majoria de plans de resposta a incidents que o bé falta completament o bé està escrita amb tant detall tècnic que només una persona de l’organització la pot seguir. Ambdues versions fallen sota pressió.
Els procediments de recuperació han de ser prou específics per ser accionables i prou clars per ser seguits per algú que estigui estressat, treballi sota pressió de temps i que potser no sigui la persona habitual en aquest rol.

• Passos inicials de contenció: com aïllar els sistemes afectats sense destruir les proves necessàries per a la investigació
• A qui notificar en cada etapa de la resposta i en quin ordre
• Passos per activar les còpies de seguretat, incloent-hi on s’emmagatzemen les credencials de còpia de seguretat i com es verifica la restauració
• Una ruta d’escalada clara: què passa si la resposta inicial no conté l’incident dins d’un termini definit
• Requisits de documentació: què cal registrar durant tot l’incident i per què (preservació de proves amb finalitats legals i d’assegurances)

Tant amb AVG com amb Cyberbeveiligingswet, les organitzacions poden haver de demostrar què va passar, quan i com van respondre. El registre en temps real durant un incident no és intuïtiu: la gent se centra en solucionar el problema, no en documentar-lo. Assigneu una persona específicament per mantenir un registre d’incidents, fins i tot si només són notes amb marca de temps en un bloc de notes físic.

Un pla de resposta a incidents que mai s’ha provat és un document, no un pla. La bretxa entre els dos només es fa visible en el pitjor moment possible.
Les proves tenen dos propòsits. Primer, revelen llacunes que no són òbvies sobre el paper: un número de contacte que està desactualitzat, un procés de restauració de còpies de seguretat que triga tres vegades més del que s’estimava, una descripció de rol que dues persones pensaven que totes dues posseïen. Segon, construeix el tipus de memòria muscular que permet a les persones respondre ràpidament i amb calma quan es produeix un incident real, en lloc de llegir el pla per primera vegada sota pressió.

• Un exercici de simulació com a mínim un cop l’any: una revisió estructurada d’un escenari d’incident simulat amb les persones clau que figuren al vostre pla. No cal tocar cap sistema, només la conversa de «què faríem realment si això passés?».
• Una prova de restauració de còpies de seguretat com a mínim dues vegades l’any: podeu restaurar realment des de la vostra còpia de seguretat més recent i quant de temps triga?
• Una revisió de la llista de contactes cada sis mesos: algú ha canviat de rol, ha deixat l’empresa o ha canviat el seu número de mòbil?
• Una revisió posterior a l’incident després de qualsevol incident real, per petit que sigui: què ha funcionat, què no i què cal canviar al pla?

Segons la Cyberbeveiligingswet, s’espera que les entitats essencials puguin demostrar que les mesures de ciberseguretat, inclosa la resposta a incidents, s’implementen i es proven. Això significa mantenir registres de les proves, exercicis de simulació i revisions del pla. Un pla amb un historial de revisions i un registre de proves és significativament més defensable que un amb una data de creació de fa tres anys i sense evidència d’actualitzacions.

Un bon pla de resposta a incidents no evita incidents. El que fa és escurçar el període entre la detecció i la contenció, reduir el cost de la recuperació i donar al vostre equip alguna cosa a seguir quan la situació és massa estressant per pensar amb claredat.
Per a les empreses holandeses, la urgència ha augmentat. El Cyberbeveiligingswet ara és llei. Les obligacions d’informe d’incidents NIS2 estan actives. Els qüestionaris dels proveïdors dels clients més grans pregunten directament si heu documentat i provat els procediments de resposta a incidents. La pregunta ja no és si cal tenir un pla, sinó si el vostre cobreix les sis coses que realment importen quan alguna cosa va malament.

La majoria de les empreses que tenen un pla de resposta a incidents descobreixen buits la primera vegada que el proven. Les que descobreixen buits durant un incident real paguen molt més per tancar-los.

Sense argot tècnic. Sense obligació. Només una imatge clara d’on es troba el vostre pla i què, si és que cal reforçar.