Gobernanza del pago de rescates por ransomware para NIS2 y DORA

Son las 3:17 de la madrugada de un día laborable de 2026. María, la CISO de una plataforma fintech en rápido crecimiento, se incorpora a un puente de crisis tras recibir un mensaje de su analista principal del SOC: cifrado generalizado confirmado, servicios esenciales caídos y un grupo de ransomware que afirma haber robado 2 TB de datos de clientes.

El director general se une primero a la llamada. Después se incorporan los equipos jurídico, de privacidad, finanzas y comunicaciones, la aseguradora de ciberriesgo, un proveedor forense y el equipo de operaciones en la nube. Un portal de la dark web muestra una cuenta atrás de 48 horas y una exigencia de siete cifras en criptomonedas.

El director general formula la pregunta que todo CISO teme.

“¿Podemos pagar y quién está autorizado a decidirlo?”

La respuesta equivocada es tratarlo como un problema de negociación. La respuesta correcta es tratarlo como un problema de gobernanza.

En 2026, la gobernanza de las decisiones de pago de rescates por ransomware ya no es una decisión privada y técnica adoptada durante una crisis. Puede ser examinada por reguladores, auditores, aseguradoras, clientes, fuerzas y cuerpos de seguridad, accionistas y el consejo de administración. Una decisión de pago se cruza con la exposición a sanciones, la evaluación de brechas de seguridad de los datos personales, las condiciones del ciberseguro, las obligaciones contractuales, las comunicaciones de crisis, la preservación de evidencias, la notificación escalonada NIS2, la clasificación de incidentes DORA, la notificación GDPR y la mejora posterior al incidente.

Por eso Clarysec recomienda a sus clientes integrar la gobernanza de las decisiones de pago de rescates por ransomware en el SGSI antes del incidente. ISO/IEC 27001:2022 aporta la estructura del sistema de gestión. Los controles ISO/IEC 27002:2022 proporcionan el modelo operativo. Zenith Blueprint: hoja de ruta de 30 pasos para auditores y Zenith Controls: guía de cumplimiento cruzado ayudan a convertir esa estructura en evidencias prácticas y auditables.

Un playbook de ransomware que diga “notificar al área jurídica” no basta. La organización debe saber quién puede autorizar la negociación, cómo se realiza la verificación frente a listas de sanciones, cuándo debe aprobar la aseguradora, cómo se documenta la clasificación GDPR, NIS2 y DORA, y cómo se protegen las evidencias mientras los equipos de recuperación trabajan bajo presión.

Por qué fallan las decisiones ad hoc de pago de rescates por ransomware

Una decisión de pago de rescate por ransomware suele describirse como binaria: pagar o no pagar. En realidad, la decisión tiene al menos seis capas:

1. ¿El evento está confirmado, contenido y clasificado correctamente?
2. ¿Están afectados datos personales, datos regulados o la prestación de servicios críticos?
3. ¿La organización está legalmente autorizada a comunicarse o realizar transacciones con el actor de amenazas?
4. ¿El ciberseguro exige notificación previa, proveedores aprobados, consentimiento o evidencias específicas?
5. ¿El pago reduciría el impacto en las operaciones de la organización o aumentaría el riesgo legal, financiero y reputacional?
6. ¿Quién tiene autoridad para decidir y cómo se registra esa decisión?

Durante un incidente en curso, los equipos desconectados suelen tirar en direcciones distintas. El CFO puede ver el rescate como un gasto de negocio frente a una indisponibilidad creciente. El área jurídica ve sanciones, delito financiero y exposición regulatoria. El DPO evalúa si los datos cifrados o exfiltrados generan una brecha de seguridad de los datos personales notificable. Cumplimiento vigila los relojes de notificación de NIS2 y DORA. El CISO intenta preservar evidencias mientras restaura los servicios. El director general quiere una recomendación antes de que expire el temporizador del atacante.

Sin un proceso formal de decisión, la voz más fuerte de la sala puede convertirse en el modelo de gobernanza. Esa es exactamente la situación que la regulación moderna de ciberseguridad pretende evitar.

NIS2 convierte la ciberseguridad en una responsabilidad de la dirección. Article 20 aborda la gobernanza y la responsabilidad proactiva de los órganos de dirección, mientras que Article 21 exige medidas de gestión de riesgos que cubran gestión de incidentes, continuidad del negocio, gestión de copias de seguridad, gestión de crisis, seguridad de la cadena de suministro, control de acceso, gestión de activos, MFA y evaluación de la eficacia. Article 23 crea una notificación escalonada para incidentes significativos, incluida una alerta temprana en 24 horas, una notificación en 72 horas y un informe final en el plazo de un mes cuando sea aplicable.

Para las entidades financieras, DORA es el marco sectorial de resiliencia operativa. Article 5 atribuye al órgano de dirección la responsabilidad sobre la gestión del riesgo de las TIC. Articles 17, 18 y 19 abordan la gestión, clasificación y notificación de incidentes graves relacionados con las TIC. DORA también exige capacidades de respuesta y recuperación, copia de seguridad y restauración, aprendizaje posterior al incidente, pruebas y gestión del riesgo de terceros TIC.

GDPR añade una evaluación separada, aunque solapada. Si el ransomware causa destrucción, pérdida, alteración, divulgación no autorizada o acceso accidental o ilícito a datos personales, el responsable del tratamiento debe evaluar si se ha producido una brecha de seguridad de los datos personales. Si se requiere notificación, el reloj de la autoridad de control suele ser de 72 horas desde que se tiene constancia. Si existe un alto riesgo para las personas, también puede exigirse la comunicación a las personas afectadas.

La conclusión es sencilla: la pregunta sobre el rescate no debe plantearse por primera vez dentro de la sala de crisis.

Controles ISO 27001:2022 que sustentan la gobernanza de pagos

Un SGSI ISO/IEC 27001:2022 no es una lista de verificación para auditores. Es un sistema de gestión para tomar decisiones basadas en riesgos. La gobernanza del pago de rescates por ransomware pertenece a ese sistema porque combina evaluación de riesgos, tratamiento de riesgos, roles, obligaciones legales, respuesta a incidentes, continuidad, gestión de proveedores y mejora continua.

Los controles más relevantes del Anexo A de ISO 27001:2022 forman una cadena de control conectada.

En Zenith Controls, la sección de A.5.24, Planificación y preparación de la gestión de incidentes de seguridad de la información, clasifica el control como correctivo, vinculado a la confidencialidad, integridad y disponibilidad, y alineado con los conceptos de respuesta y recuperación. También vincula A.5.24 con la evaluación de eventos A.5.25, el aprendizaje de incidentes A.5.27, el registro de eventos A.8.15, la supervisión A.8.16, la seguridad durante interrupciones A.5.29, la continuidad y el contacto con las autoridades.

Esto importa porque la gobernanza del pago de rescates por ransomware es una cadena. Si no puede detectar y clasificar el evento, no puede decidir. Si no puede preservar evidencias, no puede defender la decisión. Si las obligaciones legales no están mapeadas, la negociación o el pago pueden ser ilícitos. Si las opciones de recuperación no se han probado, la alta dirección puede verse presionada a decidir por miedo y no por hechos.

Zenith Controls expresa con claridad la relación entre preparación y toma de decisiones:

“5.25 es el punto de decisión que determina cuándo un evento cruza el umbral para convertirse en un incidente de seguridad, activando las acciones descritas en 5.26. Una evaluación oportuna y precisa del evento garantiza que la respuesta a incidentes no se retrase ni se desvíe.”

La misma guía vincula A.5.31, Requisitos legales, estatutarios, reglamentarios y contractuales, con privacidad, conservación de registros, revisión independiente y cumplimiento de políticas internas. Para ransomware, A.5.31 es donde la verificación frente a listas de sanciones, las obligaciones del seguro, la relación con las fuerzas y cuerpos de seguridad, los contratos con clientes, los deberes de protección de datos y la notificación regulatoria sectorial se recogen en un único registro de cumplimiento.

El modelo de cinco puertas de Clarysec para la gobernanza del pago de rescates por ransomware

El modelo de Clarysec separa la gobernanza de las decisiones de pago de rescates por ransomware en cinco puertas. El objetivo no es facilitar el pago. Es hacer que cualquier decisión, incluida la negativa a pagar, esté basada en evidencias, revisada jurídicamente, autorizada y sea auditable.

Este modelo utiliza la lógica de tratamiento de riesgos de ISO 27001. Un pago de rescate por ransomware no es un control de seguridad. Como mucho, es una opción de crisis considerada dentro de un contexto de tratamiento del riesgo y recuperación. Antes de un incidente, la organización ya debería haber decidido cómo se tratan los riesgos de ransomware: mitigarlos mediante controles, transferir parte de la exposición financiera mediante seguros, evitar dependencias heredadas inaceptables o aceptar explícitamente el riesgo residual cuando esté justificado.

En la fase de Gestión de riesgos, Step 13, Planificación del tratamiento del riesgo y Declaración de Aplicabilidad, Zenith Blueprint indica a las organizaciones que determinen las opciones de tratamiento para cada riesgo y las documenten en el Registro de Riesgos. Advierte que la transferencia, como el ciberseguro, no elimina la necesidad de controles, porque la transferencia suele abordar el impacto financiero y no la probabilidad. También afirma:

“La aceptación debe ser explícita y aprobada por la dirección, especialmente para cualquier riesgo Medio. Los riesgos Altos rara vez se aceptan salvo que sean realmente inevitables y se acuerden al máximo nivel.”

Esa frase es directamente relevante para la gobernanza del pago de rescates por ransomware. Si se pide al consejo que acepte el riesgo residual de negarse a pagar, o el riesgo legal y reputacional de aprobar una negociación, la aceptación debe ser explícita, registrada y aprobada por la autoridad adecuada.

La Política de gestión de riesgos de Clarysec refuerza el mismo punto:

“Las decisiones de tratamiento del riesgo deberán alinearse con las opciones predefinidas”
De la cláusula 5.5.

Por tanto, una decisión sobre rescate no es un atajo que evite la gestión de riesgos. Debe tratarse como una decisión formal y documentada de tratamiento del riesgo bajo una autoridad definida.

Autoridad de la política: ¿quién puede decidir bajo presión?

Muchos fallos de ransomware son fallos de gobernanza disfrazados de fallos técnicos. Alguien contacta con el atacante fuera del canal aprobado. Alguien promete el pago antes de la aprobación de la aseguradora. Alguien restaura sistemas y sobrescribe evidencias forenses. Alguien informa a los clientes demasiado pronto, demasiado tarde o con datos inexactos.

Las políticas de Clarysec están diseñadas para eliminar esa ambigüedad.

Para pymes, la Política de funciones y responsabilidades de gobernanza para pymes establece una regla sencilla:

“Todas las decisiones, excepciones y escalados significativos de seguridad deben registrarse y ser trazables.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.5.

La Política de respuesta a incidentes para pymes asigna la autoridad de escalado:

“El Director General (DG) es responsable de autorizar todas las decisiones de escalado de incidentes, notificaciones regulatorias y comunicaciones externas.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.1.1.

También conecta los incidentes de datos de clientes con las obligaciones regulatorias:

“Cuando haya datos de clientes implicados, el Director General debe evaluar las obligaciones legales de notificación en función de la aplicabilidad de GDPR, NIS2 o DORA.”
De la sección “Tratamiento de riesgos y excepciones”, cláusula de política 7.4.1.

Para organizaciones de mayor tamaño, la Política de funciones y responsabilidades de gobernanza empresarial exige el escalado inmediato cuando pueda existir exposición legal o brechas de datos notificables:

“Escalado legal/regulatorio: los incidentes que impliquen exposición legal potencial o brechas de datos notificables deberán escalarse de inmediato al Responsable Jurídico y de Cumplimiento Normativo y a la alta dirección.”
De la sección “Requisitos de implementación de la política”, cláusula de política 6.4.3.

La Política de Respuesta a Incidentes empresarial define la autoridad ejecutiva durante incidentes graves. La cláusula 4.6.1 establece que el rol del equipo de alta dirección consiste en:

“Tomar decisiones estratégicas durante incidentes de alta severidad, incluida la aprobación de notificaciones y comunicaciones públicas.”

En un contexto de ransomware, Clarysec trata la discusión sobre el pago, la autorización de negociación, el aviso a clientes, la declaración regulatoria y la comunicación pública como decisiones estratégicas, no como acciones técnicas.

De ello se deriva una regla práctica de gobernanza: el CISO puede recomendar, el equipo de incidentes puede evaluar, el área jurídica puede asesorar, finanzas puede validar la mecánica del pago, la aseguradora puede consentir o denegar cobertura, pero la alta dirección o el consejo de administración deben asumir la decisión conforme a una autoridad predefinida.

Escalado seguro frente a sanciones antes de cualquier negociación

Un proceso de ransomware seguro frente a sanciones empieza con una prohibición: ningún empleado, contratista, proveedor, intermediario, negociador o respondedor de incidentes puede negociar, prometer, facilitar o transferir valor a un actor de amenazas sin una revisión jurídica aprobada.

El punto de control jurídico debe producirse antes de cualquier interacción activa con el atacante, no después de que aparezca una dirección de monedero. El proceso debe incluir:

• Intervención de asesores jurídicos antes de cualquier comunicación distinta de la captura pasiva de evidencias.
• Identificación del actor de amenazas mediante aportaciones forenses, de inteligencia y de fuerzas y cuerpos de seguridad cuando estén disponibles.
• Verificación frente a listas de sanciones y partes restringidas para nombres de grupos, alias, direcciones de monederos, infraestructura, intermediarios y canales de pago.
• Consulta a fuerzas y cuerpos de seguridad considerada y registrada.
• Notificación a la aseguradora de ciberriesgo conforme a los términos de la póliza antes de designar proveedores o iniciar negociaciones.
• Intervención del DPO o del responsable de privacidad si pueden estar implicados datos personales.
• Confirmación por parte del CFO o responsable financiero de los controles de pago, segregación de funciones, comprobaciones antifraude y requisitos de aprobación del consejo.
• Decisión ejecutiva registrada con las alternativas consideradas, incluida restauración, contención, suspensión del servicio, comunicación a clientes y negativa a pagar.
• Evidencias preservadas sobre comunicaciones del atacante, indicadores, detalles de monederos, reuniones de decisión, aprobaciones y asesoramiento externo.

Para ransomware, el registro legal debe incluir al menos las siguientes fuentes de obligaciones.

Las organizaciones también deben definir quién puede detener la decisión de pago. El área jurídica, cumplimiento, el DPO, los asesores en sanciones o el consejo deben tener autoridad explícita para pausar la negociación o el pago si la verificación está incompleta, las evidencias no son fiables, las condiciones de la aseguradora no se cumplen o la acción puede infringir la ley o el contrato.

Preservación de evidencias: no destruya las pruebas mientras restaura el servicio

Los equipos que responden a ransomware tienden naturalmente a apresurarse para restaurar las operaciones. Pero si la restauración destruye registros, instantáneas, notas de rescate, muestras de malware, imágenes de memoria o mensajes del atacante, la organización puede perder la capacidad de demostrar qué ocurrió.

En la fase Controls in Action, Step 23, Controles organizativos, Zenith Blueprint indica a las organizaciones que validen y prueben las capacidades de gestión de incidentes mediante la definición de eventos de seguridad notificables, la documentación de la toma de decisiones y la preservación de evidencias forenses. Indica a los equipos que:

“Capturen y registren todas las decisiones, roles y comunicaciones (5.26), y actualicen el plan con las lecciones aprendidas (5.27). Confirmen que existen procedimientos para preservar evidencias forenses (5.28), incluidas instantáneas de registros, copias de seguridad y aislamiento seguro de los sistemas afectados.”

El mismo paso explica A.5.28 con un lenguaje que todo consejo debería entender:

“lo que puede demostrar importa tanto como lo que realmente ocurrió”

La Política de recopilación de evidencias y análisis forense empresarial de Clarysec refuerza que las evidencias deben seguir siendo trazables:

“Un registro de cadena de custodia deberá acompañar toda evidencia física o digital desde el momento de la adquisición hasta el archivo o la transferencia, y deberá documentar:”
De la sección “Requisitos de gobernanza”, cláusula de política 5.6.

Para pymes, la Política de recopilación de evidencias y análisis forense para pymes es deliberadamente práctica:

“Siempre debe crearse una copia forense o exportación; la evidencia original nunca debe editarse directamente.”
De la sección “Requisitos de implementación de la política”, cláusula de política 6.1.1.

También exige consulta jurídica cuando pueda existir impacto de recursos humanos, legal o sobre clientes:

“Si el incidente implica un posible impacto de Recursos Humanos (RR. HH.), legal o sobre clientes, el DG debe consultar con asesores jurídicos antes de proceder con la aplicación o el escalado.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.4.2.

Durante la Puerta 2 debe abrirse un paquete práctico de evidencias. Cree una carpeta restringida de evidencias del incidente. Exporte cronologías SIEM, detecciones EDR, registros de auditoría en la nube, registros de inicio de sesión del proveedor de identidad, estado de trabajos de copia de seguridad, notas de rescate, capturas de pantalla, mensajes del atacante, direcciones de monederos, muestras de archivos, referencias de asesoramiento jurídico, correspondencia con la aseguradora y decisiones de reuniones. Asigne un custodio. Registre valores hash cuando proceda. No permita que los administradores limpien sistemas afectados antes de la adquisición forense, salvo que la seguridad de las personas, la protección de servicios críticos o una contención aprobada por la alta dirección lo exijan.

Una única hoja de clasificación para NIS2, DORA y GDPR

Un incidente de ransomware puede activar varios relojes. El reto no es solo conocer los plazos. Es saber cuándo la organización tuvo constancia, qué sabía en ese momento y cómo se tomaron las decisiones de clasificación.

NIS2 Article 23 exige que las entidades esenciales e importantes notifiquen al CSIRT o a la autoridad competente sin dilación indebida los incidentes significativos. La significatividad se vincula a una perturbación operativa grave, pérdidas financieras o daños materiales o inmateriales considerables a terceros. El modelo escalonado incluye alerta temprana en 24 horas, notificación en 72 horas, actualizaciones intermedias si se solicitan y un informe final en el plazo de un mes desde la notificación del incidente cuando sea aplicable.

DORA exige que las entidades financieras definan e implanten la gestión de incidentes relacionados con las TIC, registren incidentes y amenazas cibernéticas significativas, clasifiquen incidentes utilizando criterios como clientes afectados, duración, extensión geográfica, pérdida de datos, criticidad e impacto económico, y notifiquen los incidentes graves relacionados con las TIC a las autoridades competentes mediante informes iniciales, intermedios y finales.

GDPR plantea una pregunta distinta, aunque solapada: ¿el incidente causó una brecha de seguridad de los datos personales? En caso afirmativo, ¿es probable que suponga un riesgo para las personas? Si se cumple el umbral de notificación, la notificación a la autoridad de control debe evaluarse frente al reloj de 72 horas. Si existe un alto riesgo, también puede ser necesaria la comunicación a las personas.

Clarysec recomienda operar una única hoja de clasificación de ransomware con secciones separadas para cada régimen.

Este enfoque encaja con las cláusulas ISO 27001 sobre evaluación de riesgos, tratamiento de riesgos e información documentada. También se alinea con NIST CSF 2.0. La función GOVERN de NIST CSF 2.0 espera que las organizaciones comprendan a las partes interesadas, las obligaciones legales y regulatorias, el apetito de riesgo, los roles, la política, la supervisión y el riesgo de terceros. Sus resultados de detección, respuesta y recuperación apoyan la declaración de incidentes, el análisis, la coordinación de la respuesta, la notificación a partes interesadas, la ejecución de la recuperación y la validación de la restauración.

Para entidades financieras, DORA puede funcionar como el régimen sectorial de ciberseguridad para obligaciones NIS2 solapadas, pero eso no elimina la necesidad de entender la aplicabilidad de NIS2 para entidades del grupo, proveedores TIC, servicios gestionados o dependencias de servicios en la nube. La respuesta práctica no es mantener playbooks separados. Es ejecutar un único modelo de evidencias del SGSI mapeado a todas las obligaciones relevantes.

El ciberseguro y la coordinación con proveedores son controles de gobernanza

El ciberseguro puede ser valioso, pero no es una estrategia frente al ransomware. Es un mecanismo de transferencia de riesgos con condiciones. Durante un evento de ransomware, la aseguradora puede exigir notificación inmediata, uso de firmas del panel, aprobación previa para negociar, preservación de evidencias, prueba de fallo de copias de seguridad, prueba de controles razonables y revisión jurídica antes de considerar cualquier pago.

DORA convierte el riesgo de terceros TIC en un dominio de cumplimiento de primer nivel. NIS2 Article 21 también exige seguridad de la cadena de suministro y consideración de vulnerabilidades de proveedores y prácticas de ciberseguridad. ISO 27001 respalda la misma lógica mediante controles de proveedores y nube como A.5.19 a A.5.23, además de controles de incidentes, continuidad y requisitos legales.

Zenith Controls vincula la preparación ante incidentes con socios externos, incluidas firmas forenses, asesoría jurídica, relaciones públicas y contacto con autoridades. Desde la perspectiva de auditoría, la ausencia de socios externos preidentificados puede considerarse una deficiencia de preparación porque puede retrasar la respuesta durante un incidente real.

Para la gobernanza del pago de rescates por ransomware, Clarysec recomienda preacordar:

• Retenedor forense o condiciones de respuesta rápida.
• Disponibilidad de asesores jurídicos externos para brechas, sanciones y estrategia de privilegio.
• Ruta de notificación a la aseguradora de ciberriesgo y lista de proveedores aprobados.
• Ruta de escalado del proveedor de servicios en la nube para instantáneas, registros, aislamiento y recuperación.
• Procedimientos de colaboración en incidentes con MSSP o MDR.
• Proceso de revisión de relaciones públicas y comunicaciones de crisis.
• Controles de aprobación bancaria o financiera para cualquier pago extraordinario.
• Protocolo de contacto con fuerzas y cuerpos de seguridad.

Esto mapea bien con los resultados de cadena de suministro de NIST CSF 2.0, incluidos roles y responsabilidades de proveedores, diligencia debida, requisitos contractuales de ciberseguridad, coordinación de incidentes de proveedores y actividades posteriores a la terminación.

Un playbook práctico de escalado de pagos de rescates por ransomware

Las cinco puertas pueden traducirse en un playbook operativo. Cada paso debe estar documentado, tener propietario y ensayarse.

El objetivo no es garantizar una decisión cómoda. Puede que no exista una decisión cómoda. El objetivo es garantizar que la decisión esté autorizada, basada en evidencias, informada jurídicamente y sea defendible.

El ejercicio de mesa de 90 minutos que demuestra la preparación

La forma más sencilla de probar la gobernanza del pago de rescates por ransomware no es un red team técnico. Es un ejercicio de mesa de decisión.

Utilice Zenith Blueprint, fase Controls in Action, Step 23, para validar la capacidad de gestión de incidentes. Seleccione un escenario de ransomware y ejecute un ejercicio cronometrado. El objetivo no es decidir por adelantado que la organización pagaría o nunca pagaría. El objetivo es demostrar que la organización puede llegar a una decisión gobernada.

Escenario: una base de datos de clientes alojada en la nube está cifrada, el atacante afirma que ha exfiltrado datos, existen copias de seguridad pero aún no se ha verificado su integridad, la aseguradora no ha sido notificada y el atacante proporciona una dirección de monedero con un plazo de 48 horas.

Lista de verificación del ejercicio:

• Declarar el incidente y asignar el Comandante del incidente.
• Abrir el registro de decisiones sobre ransomware.
• Clasificar el evento utilizando los criterios A.5.25.
• Identificar activos y servicios de negocio afectados.
• Determinar si hay datos personales implicados.
• Activar flujos de trabajo de evaluación GDPR, NIS2, DORA y contractual.
• Notificar al área jurídica, DPO, alta dirección, aseguradora y proveedor forense.
• Preservar evidencias antes de acciones de recuperación destructivas.
• Verificar la integridad de las copias de seguridad y las opciones de restauración.
• Realizar la verificación frente a listas de sanciones antes de cualquier negociación.
• Registrar si se requiere consulta con fuerzas y cuerpos de seguridad.
• Redactar declaraciones preliminares para clientes y reguladores.
• Presentar opciones de decisión a la autoridad ejecutiva.
• Registrar decisión, justificación, discrepancias, aprobaciones y siguientes acciones.
• Programar la revisión posterior al incidente y las acciones de mejora de controles.

El resultado debe ser un paquete completo de evidencias: lista de asistencia, cronología, hoja de clasificación, registro de decisiones, borradores de comunicaciones, acciones legales, acciones de la aseguradora, hallazgos sobre copias de seguridad y lecciones aprendidas. Ese paquete es oro de auditoría porque demuestra que la gobernanza funciona antes de una crisis real.

Cómo auditores y reguladores probarán el proceso

Auditores de distintos perfiles examinarán el mismo proceso de ransomware con enfoques diferentes.

Zenith Controls proporciona metodología de auditoría detallada para A.5.24, A.5.25 y A.5.31. Para A.5.24, los auditores examinan el plan de respuesta a incidentes, clasificaciones de gravedad, roles, listas de contactos, instrucciones de notificación regulatoria, ejercicios y acuerdos con socios externos. Para A.5.25, revisan si existen criterios de clasificación de eventos, si los registros de gestión de alertas muestran decisiones de investigación y escalado, si se utilizan SIEM e inteligencia de amenazas, y si los equipos de DPO o del área jurídica intervienen cuando pueden verse afectados datos personales. Para A.5.31, los auditores buscan registros legales, mapeo de cumplimiento, evidencias de revisión, cobertura de auditoría interna e informes a la alta dirección.

El riesgo de auditoría no consiste solo en que una organización haya pagado o se haya negado a pagar. El riesgo de auditoría es que nadie pueda demostrar cómo se tomó la decisión.

De la extorsión a la mejora de controles

La gobernanza del ransomware no termina cuando se restauran los sistemas. ISO 27001 espera mejora continua. A.5.27 aprendizaje a partir de incidentes de seguridad de la información es central para esa expectativa. DORA exige análisis de causa raíz y controles adicionales. La notificación final NIS2 espera medidas de mitigación y causa raíz probable cuando sea aplicable. La responsabilidad proactiva de GDPR espera documentación de decisiones y salvaguardas.

Toda revisión posterior al incidente de ransomware debe responder:

• ¿Se identificaron correctamente los relojes de notificación?
• ¿La autoridad de decisión funcionó según lo diseñado?
• ¿La revisión legal y de sanciones fue lo bastante temprana?
• ¿La coordinación con la aseguradora ayudó o retrasó la respuesta?
• ¿Las copias de seguridad estaban completas, segregadas, restaurables y probadas?
• ¿Los registros fueron suficientes para evaluar accesos y exfiltración?
• ¿Los proveedores respondieron conforme al contrato?
• ¿Las comunicaciones a clientes fueron precisas y oportunas?
• ¿La alta dirección recibió la información correcta en el momento adecuado?
• ¿Qué controles, políticas, contratos o formación deben cambiar?

Esas respuestas deben actualizar el registro de riesgos, la Declaración de Aplicabilidad, el plan de respuesta a incidentes, la estrategia de copias de seguridad, los contratos con proveedores, el plan de comunicaciones y el programa de formación.

En la fase ISMS Foundation and Leadership, Step 5, Zenith Blueprint destaca la planificación de comunicaciones externas, incluida la identificación de clientes, reguladores, socios y público, la determinación de qué comunicar y cuándo, y la definición de quién comunica. Para ransomware, ese paso se convierte en el puente entre la respuesta técnica y la preservación de la confianza.

Construya el registro de decisión antes de la nota de rescate

El mejor momento para gobernar una decisión de rescate es antes de que el atacante fije el plazo.

Si su playbook de ransomware no define autoridad de decisión, revisión legal, verificación frente a listas de sanciones, aprobación de la aseguradora, preservación de evidencias, clasificación NIS2 y DORA, evaluación de brecha GDPR y documentación a nivel de consejo, la organización tiene una deficiencia de gobernanza esperando una crisis.

Clarysec ayuda a las organizaciones a incorporar esta capacidad en el SGSI mediante:

• Zenith Blueprint: hoja de ruta de 30 pasos para auditores para implementación ISO 27001 por fases, tratamiento de riesgos, planificación de comunicaciones y validación de capacidades de incidentes.
• Zenith Controls: guía de cumplimiento cruzado para mapear controles ISO 27001 con NIS2, DORA, GDPR, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 y evidencias de auditoría.
• Políticas empresariales y para pymes de Clarysec, incluidas Política de Respuesta a Incidentes, Política de Respuesta a Incidentes - Pyme, Política de recopilación de evidencias y análisis forense, Política de recopilación de evidencias y análisis forense - Pyme, Política de funciones y responsabilidades de gobernanza, Política de funciones y responsabilidades de gobernanza - Pyme y Política de gestión de riesgos.
• Plantillas prácticas de ejercicios de mesa de ransomware, registros de decisión, matrices de escalado legal, paquetes de evidencias y hojas de notificación de cumplimiento cruzado.

No espere a la llamada de las 3 de la madrugada para descubrir quién puede decidir. Revise su plan de respuesta a incidentes frente a las cinco puertas de Clarysec, ejecute un ejercicio de mesa de 90 minutos sobre pago de rescates por ransomware y construya un registro de decisión seguro frente a sanciones y preparado para auditorías, capaz de resistir el escrutinio de reguladores, aseguradoras y su propio consejo de administración.