CSRD y ciberseguridad: por qué el reporte de sostenibilidad ya incluye el gobierno del riesgo digital

La CSRD no menciona el ransomware como una categoría de sostenibilidad ni convierte al CISO en responsable de redactar el informe anual. Tampoco crea un nuevo marco técnico de controles de seguridad. Su efecto es menos vistoso y, para muchas empresas, más incómodo: obliga a explicar cómo se gobiernan los riesgos que pueden afectar de forma material al negocio, a las personas y a la cadena de valor. El riesgo digital puede entrar por esa puerta.

La diferencia no es semántica. Un ataque que paraliza una red hospitalaria, expone datos de clientes, interrumpe pagos o deja sin servicio una plataforma crítica no es únicamente un incidente tecnológico. Puede generar impactos sobre derechos, empleados, clientes, proveedores, ingresos, reputación, continuidad operativa y acceso a servicios esenciales. Cuando esos efectos alcanzan el umbral de materialidad exigido por la Directiva, la cuestión deja de ser si la empresa quiere contar algo sobre ciberseguridad. La cuestión pasa a ser si puede justificar por qué no lo cuenta.

Aquí está el cambio de enfoque para un CISO: el informe de sostenibilidad no debe tratarse como otra encuesta corporativa que llega desde el departamento financiero en octubre. Puede convertirse en una prueba pública de la calidad del gobierno del riesgo digital. Y esa prueba se prepara con decisiones, controles y evidencias; no con una frase sobre que la organización “toma la seguridad muy en serio”.

La tesis: la CSRD no regula el SOC, pero sí puede exigir explicaciones sobre sus consecuencias

La Directiva (UE) 2022/2464, que modificó las reglas europeas de información corporativa, introdujo obligaciones de reporte de sostenibilidad en la Directiva contable. Para las empresas incluidas en su ámbito, el artículo 19 bis exige incorporar información de sostenibilidad en el informe de gestión. En grupos, el artículo 29 bis extiende esa obligación al informe de gestión consolidado.

El contenido no se limita a emisiones, diversidad o consumo energético. El artículo 19 bis abarca, entre otros elementos, el modelo de negocio y la estrategia, los objetivos y políticas de sostenibilidad, las acciones emprendidas, los principales riesgos y oportunidades relacionados con cuestiones de sostenibilidad y la forma en que se gestionan. El artículo 29 bis aplica una lógica equivalente a la información consolidada.

La palabra decisiva es “relacionados”. La CSRD no crea una lista cerrada de temas digitales que toda compañía deba reportar. Obliga a identificar las cuestiones materiales mediante el principio de doble materialidad. Una cuestión puede ser material por impacto —porque la empresa causa, contribuye o está vinculada a efectos significativos sobre personas o medio ambiente—, por su relevancia financiera —porque genera riesgos u oportunidades que pueden afectar a la posición financiera, los resultados, los flujos de caja o el acceso a financiación—, o por ambas vías.

El riesgo digital puede encajar en las dos.

Un fallo de autenticación que expone historiales médicos puede producir un impacto material sobre la privacidad y los derechos de los afectados. Una interrupción prolongada del sistema de negociación de una entidad financiera puede tener consecuencias financieras directas y afectar a clientes y mercados. Una intrusión en un proveedor de software puede revelar datos de trabajadores o detener una planta industrial. La tecnología es el mecanismo; la materialidad se decide por las consecuencias.

Esto evita una confusión frecuente. La CSRD no exige publicar la arquitectura del Centro de Operaciones de Seguridad, el nombre del proveedor de EDR o la configuración exacta del SIEM. Exige algo más cercano al gobierno corporativo: explicar, cuando sea material, quién supervisa el riesgo, qué políticas existen, cómo se identifica y gestiona, qué acciones se han tomado, qué objetivos se persiguen y cuáles son los riesgos principales.

Qué aportan realmente los ESRS de gobernanza

La Directiva define el deber de informar; los European Sustainability Reporting Standards —ESRS— concretan buena parte de la información que debe estructurarse. La Comisión Europea adoptó los estándares sector-independent mediante el Reglamento Delegado (UE) 2023/2772, publicado en diciembre de 2023. El punto de entrada para el riesgo digital no es una supuesta norma “ESRS de ciberseguridad”. No existe como tal dentro del primer conjunto sectorial. El punto de entrada está en ESRS 2, que es obligatorio para las entidades sujetas al estándar.

ESRS 2 GOV-1 pide información sobre el papel de los órganos de administración, dirección y supervisión, su composición, responsabilidades y experiencia relevante. Si el riesgo tecnológico es una amenaza material para el modelo de negocio, la empresa debe poder explicar dónde reside la responsabilidad: ¿en el consejo?, ¿en un comité de riesgos?, ¿en la dirección de operaciones?, ¿en el CISO con acceso directo al órgano de supervisión? Un organigrama que coloca al CISO bajo una cadena de mando sin capacidad de elevar riesgos críticos puede ser perfectamente legal, pero revela una realidad de gobierno que no debería maquillarse en el informe.

ESRS 2 GOV-2 se ocupa de la información proporcionada a los órganos de administración, dirección y supervisión y de las cuestiones de sostenibilidad abordadas por ellos. Para un riesgo digital material, la evidencia no es una presentación genérica de “ciberseguridad y privacidad”. Es el rastro de qué recibió el consejo, con qué periodicidad, qué métricas se discutieron, qué decisiones tomó y qué asuntos fueron escalados.

ESRS 2 GOV-3 aborda la integración del desempeño relacionado con la sostenibilidad en los sistemas de incentivos. Si una entidad declara que la resiliencia digital es una condición para proteger clientes y continuidad de negocio, pero los incentivos ejecutivos solo miden ingresos y costes, aparece una pregunta razonable: ¿el riesgo está integrado en la gestión o solo en el lenguaje corporativo?

ESRS 2 GOV-4 exige una declaración sobre diligencia debida. No convierte automáticamente la ciberseguridad en un proceso de derechos humanos, pero sí obliga a conectar la información reportada con los elementos de diligencia debida que correspondan. Cuando una empresa depende de proveedores que procesan datos personales, administran infraestructuras críticas o sostienen operaciones esenciales, la evaluación de la cadena de valor puede incluir controles de seguridad, capacidad de respuesta y consecuencias para las personas.

ESRS 2 GOV-5 se centra en la gestión de riesgos y controles internos sobre la información de sostenibilidad. Este punto tiene una consecuencia práctica que muchas organizaciones descubrirán tarde: si una métrica o afirmación sobre riesgo digital acaba dentro del informe de sostenibilidad, debe existir un proceso para producirla, revisarla, aprobarla y conservar evidencia. El control interno del reporte no es idéntico al control interno del entorno TI, pero ambos terminan tocándose.

La doble materialidad es el puente entre sostenibilidad y ciberseguridad

La evaluación de materialidad no consiste en preguntar a cada departamento qué tema le parece interesante. ESRS 1 exige identificar impactos, riesgos y oportunidades y evaluar su importancia mediante una metodología documentada. La empresa debe analizar sus operaciones, relaciones comerciales y cadena de valor, y justificar por qué una cuestión se considera material o no material.

Para el riesgo digital, la dificultad está en que sus efectos atraviesan varias categorías de reporte. Un mismo incidente puede afectar a:

• Consumidores y usuarios: indisponibilidad de servicios, fraude, discriminación por fallos de modelos, exposición de datos o pérdida de acceso.
• Trabajadores: vigilancia desproporcionada, uso inseguro de herramientas, interrupción de nóminas o exposición de información laboral.
• Socios y proveedores: dependencia de una plataforma, transferencia de datos, concentración tecnológica o falta de capacidad de recuperación.
• Resultados financieros: pérdida de ingresos, costes de respuesta, sanciones, litigios, deterioro de activos o aumento del coste de capital.
• Gobierno corporativo: decisiones de inversión, tolerancia al riesgo, responsabilidades, controles y supervisión por el consejo.

La evaluación debe separar el impacto real o potencial, positivo o negativo, de la probabilidad y magnitud del riesgo financiero. Un incidente que aún no ha ocurrido puede ser material por impacto potencial. Un ataque que no produjo una pérdida contable significativa puede seguir siendo material si afectó a un grupo vulnerable o expuso datos sensibles. La contabilidad del daño no agota la materialidad.

Este es el punto donde suelen fallar los ejercicios superficiales. Un registro de riesgos corporativos puede clasificar “ciberataque” como riesgo alto y, al mismo tiempo, la evaluación de doble materialidad puede declarar que no hay una cuestión de sostenibilidad relevante. Esa combinación no es imposible, pero exige una explicación defendible. Si el riesgo tiene una probabilidad y un impacto suficientes para estar en el mapa del comité de riesgos, la exclusión del reporte necesita una lógica que no parezca diseñada para evitar preguntas.

La inversa también es cierta. Una vulnerabilidad técnica crítica no es automáticamente una cuestión material de sostenibilidad. Un CVE concreto puede tener una puntuación CVSS elevada y no producir una consecuencia material para esa entidad. La CSRD no pide convertir el informe en un boletín de vulnerabilidades. Pide conectar los hechos técnicos con impactos y riesgos corporativos relevantes.

Qué debería buscar un auditor de sostenibilidad

La Directiva introdujo un requisito de verificación de la información de sostenibilidad. El artículo 34 de la Directiva 2013/34/UE, modificado por la CSRD, establece la intervención del auditor o proveedor independiente de servicios de aseguramiento sobre la información de sostenibilidad. El modelo europeo parte de una seguridad limitada y prevé la evolución hacia una seguridad razonable mediante estándares europeos, aunque el alcance y calendario concretos dependen de la legislación aplicable y de su desarrollo.

Para el CISO, esto modifica la pregunta. Ya no basta con demostrar que existe una política de seguridad aprobada. Habrá que demostrar que las afirmaciones reportadas tienen una base trazable y que los procesos utilizados para obtenerlas funcionan de forma consistente.

Si el informe afirma que el consejo supervisa trimestralmente el riesgo digital, el auditor puede pedir las actas, materiales y métricas que sostienen esa afirmación. Si se declara que los proveedores críticos están cubiertos por evaluaciones de seguridad, habrá que definir qué significa “cubiertos”: ¿todos los proveedores?, ¿solo los críticos?, ¿con qué criterios?, ¿qué porcentaje está evaluado?, ¿qué excepciones existen?, ¿qué remediación está abierta?

Si la compañía informa de un objetivo para reducir el tiempo de recuperación, la métrica necesita una definición operativa. ¿Se mide desde la detección, desde la declaración del incidente o desde la interrupción del servicio? ¿Incluye dependencias de terceros? ¿Se calcula por sistema, por proceso crítico o como promedio? Un objetivo elegante y metodológicamente vacío tiene una vida corta cuando alguien pide la fórmula.

La auditoría no convierte al verificador en un red team. Pero sí aumenta el valor de la evidencia que conecta gobierno, controles y resultados. Las organizaciones que mantienen la información de sostenibilidad en hojas de cálculo aisladas y conversaciones por correo tendrán dificultades para demostrar consistencia. La resiliencia del reporte también depende de la trazabilidad de los datos.

La intersección con DORA, NIS2 y el RGPD no es una excusa para copiar y pegar

Las empresas europeas ya están sometidas, según su actividad, a obligaciones específicas de ciberseguridad y notificación. DORA se aplica desde el 17 de enero de 2025 a las entidades financieras incluidas en su ámbito y regula, entre otras materias, la gestión del riesgo relacionado con las TIC en sus artículos 5 a 16, la notificación de incidentes relacionados con las TIC en los artículos 17 a 23 y el riesgo de terceros proveedores de servicios TIC en los artículos 28 a 44.

NIS2, la Directiva (UE) 2022/2555, exige en su artículo 21 medidas de gestión del riesgo de ciberseguridad y en su artículo 23 obligaciones de notificación de incidentes para entidades esenciales e importantes. El RGPD fija en su artículo 32 la seguridad del tratamiento y en el artículo 33 la notificación de violaciones de datos personales a la autoridad de control, en principio dentro de las 72 horas desde que el responsable tiene constancia de ellas, salvo que no sea probable que exista un riesgo para los derechos y libertades.

Estos regímenes proporcionan fuentes de evidencia, pero no sustituyen el análisis CSRD. Un incidente notificado bajo DORA o NIS2 no se convierte automáticamente en un asunto material de sostenibilidad. Tampoco una notificación bajo el artículo 33 del RGPD resuelve por sí sola qué debe aparecer en el informe de gestión. La empresa debe evaluar la importancia del impacto, la duración, el alcance, los grupos afectados y las consecuencias financieras y operativas.

La reutilización inteligente consiste en aprovechar un mismo hecho con distintos propósitos sin confundir los umbrales. El registro de incidentes puede alimentar la evaluación de impactos. Las pruebas de continuidad exigidas por DORA pueden respaldar la explicación sobre resiliencia operativa. Las evaluaciones de proveedores pueden servir para demostrar diligencia debida en la cadena de valor. Pero cada uso necesita su propia definición, control y responsable.

La tentación de copiar el texto de DORA en el informe CSRD es comprensible y equivocada. “Disponemos de un marco de gestión del riesgo TIC conforme a DORA” describe una obligación regulatoria. No explica si los servicios críticos resistieron las pruebas, si existen dependencias concentradas, si las deficiencias se han remediado ni qué impacto tendría una interrupción sobre clientes y trabajadores.

El riesgo de terceros convierte la ciberseguridad en una cuestión de cadena de valor

Muchas organizaciones pueden controlar sus propios centros de datos y seguir dependiendo de una pequeña concentración de proveedores de nube, identidad, pagos, telecomunicaciones o software empresarial. El incidente no necesita comenzar dentro de la empresa para afectar a sus clientes. Por eso, el análisis de materialidad que ignora proveedores estratégicos ofrece una imagen incompleta.

El artículo 28 de DORA obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC, y los artículos 29 y 30 desarrollan elementos relativos a proveedores críticos y al contenido contractual, respectivamente. En NIS2, el artículo 21.2.d menciona la seguridad de la cadena de suministro. Para CSRD, la consecuencia no es que cada contrato deba convertirse en un anexo de sostenibilidad, sino que la dependencia tecnológica puede ser una fuente material de riesgo financiero o de impacto.

Un buen expediente debería poder responder a preguntas incómodas:

• ¿Qué proveedores pueden detener un proceso crítico aunque no estén clasificados como “proveedores TIC críticos” a efectos de DORA?
• ¿Qué datos personales o datos de clientes procesan?
• ¿Qué ocurre si el proveedor tarda 24, 72 o 168 horas en restaurar el servicio?
• ¿Existe una alternativa técnica o contractual?
• ¿Se han probado los procedimientos de salida, sustitución o funcionamiento degradado?
• ¿Quién acepta el riesgo cuando una vulnerabilidad o una excepción permanece abierta?

Las respuestas no deben aparecer íntegras en un informe público si revelar detalles crearía un riesgo de seguridad. Pero sí deben existir internamente para justificar la conclusión publicada. La transparencia no significa publicar el plano del edificio; significa poder explicar por qué el edificio cumple las condiciones de seguridad que se declaran.

Qué significa “gobernar” el riesgo digital en términos de reporte

Gobernanza no equivale a tener un comité con “cyber” en el nombre. Para que la afirmación sea creíble, deben encajar al menos cinco piezas.

Primera: responsabilidad. El consejo debe conocer el perfil de riesgo y el apetito aprobado. El CISO necesita una vía clara de escalado para riesgos que superen umbrales definidos. El responsable de sostenibilidad debe saber qué información necesita y cuándo. Si todos participan pero nadie decide, no existe gobierno; existe una reunión.

Segunda: metodología. La compañía debe definir cómo traduce un evento técnico en impacto sobre personas, operaciones, finanzas y derechos. Esa metodología debería explicar la relación entre severidad del incidente, duración, población afectada, criticidad del servicio y pérdida financiera. No hace falta inventar un algoritmo sofisticado. Hace falta que el criterio sea consistente y auditable.

Tercera: controles. El inventario de activos, la gestión de vulnerabilidades, la segregación de funciones, el control de accesos privilegiados, las copias de seguridad, las pruebas de restauración, la gestión de proveedores y la respuesta a incidentes no son todos “datos de sostenibilidad”. Se convierten en evidencia cuando respaldan una afirmación material sobre resiliencia, protección de clientes o gobierno del riesgo.

Cuarta: métricas. El número de incidentes es una métrica pobre si no se acompaña de contexto. Resultan más útiles indicadores como el porcentaje de activos críticos con propietario asignado, el tiempo de corrección de vulnerabilidades críticas, la cobertura de pruebas de restauración, el porcentaje de proveedores críticos evaluados, el número de excepciones vencidas o el tiempo entre la detección y la escalada al órgano correspondiente.

Quinta: remediación. Una empresa que declara un riesgo material no necesita afirmar que lo ha eliminado. Necesita explicar las acciones emprendidas, los recursos destinados, los objetivos y el estado de avance. La honestidad sobre una brecha controlada suele ser más defendible que una declaración de perfección que los registros internos contradicen.

Una evidencia útil para el informe no es una montaña de documentos

La preparación no consiste en entregar al equipo de reporting una carpeta de 4.000 páginas. Consiste en construir una cadena de evidencia que permita ir desde la afirmación pública hasta la fuente primaria.

Para una afirmación sobre supervisión, la cadena puede ser: texto del informe, métrica de gobierno, presentación al comité de riesgos, acta de la reunión, propietario de la métrica y política que define el proceso. Para una afirmación sobre proveedores: texto publicado, universo de proveedores críticos, criterio de criticidad, resultado de evaluaciones, excepciones, planes de tratamiento y evidencia de seguimiento.

Una checklist razonable para auditoría debería incluir, como mínimo:

• La metodología de doble materialidad y la justificación de inclusión o exclusión del riesgo digital.
• El mapa de responsabilidades entre consejo, comité de riesgos, CISO, privacidad, continuidad, compras y sostenibilidad.
• Las políticas aprobadas y su fecha de revisión.
• Las métricas reportadas, sus definiciones, fórmulas, fuentes y controles de calidad.
• Las actas o materiales que demuestren la supervisión del órgano competente.
• El registro de incidentes materiales y el razonamiento aplicado para decidir si afectaban al reporte.
• La evaluación de proveedores y dependencias de cadena de valor.
• Los resultados de pruebas de continuidad, restauración y respuesta, con las deficiencias abiertas.
• La conciliación entre información CSRD, DORA, NIS2, RGPD y el informe financiero cuando describan el mismo riesgo.
• La aprobación final, las revisiones independientes y el control de cambios.

La última línea es especialmente importante. Si el informe dice que un objetivo se ha cumplido, pero el dashboard del SOC utiliza otra definición o cubre un perímetro distinto, el problema no es de estilo. Es un fallo de control interno.

La contradicción que las empresas deben resolver

Las organizaciones suelen querer dos cosas a la vez: presentar la ciberseguridad como una capacidad estratégica y evitar publicar información que pueda ayudar a un atacante. Ambas preferencias son legítimas. Lo que no funciona es usar la confidencialidad como explicación automática para no reportar nada.

ESRS 1 permite proteger información sensible en determinados supuestos, pero la reserva debe aplicarse con criterio. El informe puede describir el gobierno, los procesos y las tendencias sin revelar nombres de sistemas, configuraciones, rutas de red, indicadores de detección o vulnerabilidades explotables. “No publicamos los detalles técnicos por razones de seguridad” puede ser una decisión correcta; no puede servir para ocultar si la empresa carece de un proceso de supervisión, si un riesgo crítico está fuera de plazo o si un proveedor concentra una función esencial.

La solución editorial y de control consiste en separar tres niveles. El primero es público: la naturaleza del riesgo, su relevancia, la gobernanza, las políticas, los objetivos y las acciones. El segundo es reservado para aseguramiento y supervisión: métricas completas, incidentes, excepciones, pruebas y planes de remediación. El tercero es estrictamente operativo: configuraciones, indicadores técnicos, arquitectura y detalles que aumentarían la exposición. Confundir los tres niveles produce informes vagos o filtraciones innecesarias.

Qué debe cambiar en la agenda del CISO

El CISO no necesita convertirse en especialista en ESRS para influir en el reporte. Sí necesita participar antes de que se cierre la evaluación de materialidad y no limitarse a validar el texto final.

El primer paso es identificar los temas en los que el riesgo digital altera el impacto o la exposición financiera: privacidad, seguridad de consumidores, continuidad de servicios, dependencia de proveedores, condiciones de trabajo, derechos humanos y resiliencia del modelo de negocio. Después hay que mapearlos contra los requisitos de ESRS 2, especialmente GOV-1, GOV-2, GOV-3, GOV-4, GOV-5, SBM-3 e IRO-1.

El segundo paso es revisar el lenguaje de las afirmaciones. “La compañía cuenta con medidas adecuadas” no es una afirmación operativa hasta que se define qué medidas, para qué riesgos, con qué alcance y con qué resultado. “Se realizan pruebas periódicas” tampoco basta: la periodicidad, el perímetro, el resultado y la remediación son los datos que dan significado a la frase.

El tercero es acordar umbrales de escalado. Un incidente que active notificación bajo el RGPD, DORA o NIS2 debe entrar automáticamente en una revisión de materialidad, aunque no se publique automáticamente. Lo mismo debería ocurrir con una interrupción de un proveedor crítico, una exfiltración confirmada, una indisponibilidad prolongada o un incumplimiento de un objetivo de resiliencia. La revisión no prejuzga el resultado; evita que la decisión dependa de quién se acuerde del asunto al preparar el informe.

El cuarto es probar la información. Un ejercicio de mesa no debería limitarse a “¿qué haríamos ante un ransomware?”. Debe incluir una pregunta de reporting: ¿qué se publicaría, quién lo aprobaría, qué evidencia lo sostendría y cómo se evitaría contradecir el informe financiero, una notificación regulatoria o la comunicación a afectados?

Lo que la CSRD no permite afirmar

La CSRD no permite presentar una certificación de sostenibilidad como si fuera una certificación de seguridad. La verificación del informe no significa que todos los controles tecnológicos hayan sido auditados ni que la organización sea inmune a incidentes.

Tampoco permite convertir el cumplimiento de DORA, NIS2 o RGPD en una garantía de ausencia de impacto. Cumplir una obligación de notificación no demuestra que el riesgo esté bajo control. Disponer de un plan de respuesta no demuestra que la recuperación funcione en condiciones reales. Tener un proveedor certificado no elimina el riesgo de concentración ni sustituye la supervisión propia.

Y, sobre todo, no permite confundir una política con una capacidad. La política de gestión de vulnerabilidades demuestra que existe una norma interna. El tiempo real de corrección, el volumen de excepciones y los activos fuera de inventario muestran la capacidad. La política de copias de seguridad no restaura un servicio; una prueba documentada de recuperación sí aporta evidencia sobre esa capacidad.

La ventaja para quien se adelante

El riesgo digital suele llegar al consejo fragmentado: una alerta del CISO, una notificación de privacidad, una incidencia de proveedor, una consulta del auditor y una cifra de pérdidas en el informe financiero. La CSRD ofrece una oportunidad para unir esas piezas alrededor de una pregunta corporativa: qué riesgos puede generar la forma en que la empresa utiliza y gobierna la tecnología, y qué efectos produce sobre sus grupos de interés.

Las compañías que hagan bien ese trabajo obtendrán algo más útil que un párrafo de cumplimiento. Tendrán una visión comparables de dependencias, impactos, decisiones y resultados. Podrán detectar que un proveedor aparentemente pequeño sostiene un proceso esencial, que un objetivo de recuperación no contempla una dependencia externa o que el consejo recibe métricas sin umbrales de decisión.

Las que lo hagan mal publicarán frases impecables y difíciles de probar. La diferencia aparecerá cuando llegue un incidente, una revisión del auditor o una pregunta de un inversor: ¿por qué considerasteis material el riesgo climático y no la caída del servicio que dejó a miles de clientes sin acceso durante dos días? ¿Quién aceptó esa decisión? ¿Qué evidencia la respalda?

La CSRD no convierte la ciberseguridad en sostenibilidad por decreto. Hace algo más exigente: obliga a demostrar cuándo el riesgo digital tiene consecuencias que la empresa no puede tratar como un asunto exclusivamente técnico. Para el CISO y compliance, el trabajo empieza mucho antes de escribir el informe. Empieza cuando se decide qué riesgos llegan al consejo, qué impactos se miden y qué controles permiten sostener la historia que la compañía está a punto de contar.