Todos los artículos

Blog

Reglamento DORA, NIS2, PCI DSS: el registro no prueba la eficacia

Reglamento DORA, NIS2, PCI DSS, ISO 27001: lo que los textos exigen a los desarrolladores, lo que verifica el auditor y la prueba que falta.

  • Por Azziz ERRIME
  • 12 min de lectura
Sala de comparecencias parlamentaria vacía, sin bandera ni emblema, con un archivador cerrado ante la silla del testigo

TL;DR

  • Reglamento DORA, NIS2 o PCI DSS: los textos obligan a formar a los desarrolladores y a documentarlo, rara vez a demostrar que sus prácticas han cambiado.
  • PCI DSS exige una formación cada 12 meses, y el evaluador la comprueba examinando registros y entrevistando al personal.
  • Yo prepararía la auditoría en dos columnas: lo que se ha hecho y lo que ha cambiado en las revisiones de código.

El 3 de octubre de 2017, el ex consejero delegado de Equifax explica ante el Congreso de Estados Unidos que la alerta de seguridad sí llegó a los equipos adecuados y que se siguió el protocolo. La filtración afectaba a unos 147 millones de personas. Las obligaciones de formación de DORA, NIS2 y PCI DSS reproducen esa escena a su escala: exigen demostrar que el mecanismo existe; que funcione, bastante menos.

Ese 3 de octubre, en Washington, Richard Smith comparece ante el Comité de Energía y Comercio de la Cámara de Representantes. Equifax, avisada en marzo, no descubre la intrusión hasta julio. Ante los congresistas, repasa la cadena prevista: al día siguiente de la alerta del CERT, el equipo de seguridad avisa a un grupo amplio del equipo técnico. Esas personas tienen que localizar la vulnerabilidad y aplicar el parche, y unos días más tarde lanzar un escáner de verificación.

La cadena se rompió en un eslabón, según la transcripción de la comparecencia. Smith lo cuenta así: «The human error was the individual who is responsible for communicating in the organization to apply the patch did not.» Luego lo resume en dos tiempos: «Both human deployment of the patch and the scanning deployment did not work» y «The protocol was followed».

La FTC informa en 2019 de que la norma interna obligaba a aplicar los parches en 48 horas. El acuerdo alcanzado prevé al menos 575 millones de dólares. El protocolo se había seguido, e incluía su propia verificación. Tampoco esta detectó nada.

Seguir un protocolo no demuestra que un control funcione

La escena muestra la distancia entre dos pruebas que se confunden con facilidad. La primera dice que una acción ha tenido lugar: una alerta enviada, un escáner programado, un procedimiento firmado. La segunda dice que la acción ha cambiado algo: el parche está aplicado, el servidor ya no responde al ataque. La primera se archiva sin esfuerzo en un expediente de auditoría; la segunda, bastante menos.

El atacante no lee tus procedimientos. Busca el servidor que no recibió el parche, el formulario que nadie filtró, el pull request revisado a toda prisa. En la práctica, prueba la aplicación en producción, y lo que encuentra allí mide la eficacia real de tus controles, formación incluida.

La formación de los desarrolladores vive justo en esa distancia. Un registro dice que un desarrollador completó en marzo un módulo sobre inyección SQL. No dice si en septiembre detectó la inyección colada en el código de un compañero. ¿Se conforman con la primera prueba los textos que regulan la formación en DORA, NIS2 o PCI DSS?

La formación que piden el reglamento DORA, NIS2 o PCI DSS se verifica sobre todo en registros

La tabla se basa en los propios textos, leídos en el Diario Oficial de la Unión Europea, y en la norma PCI DSS 4.0.1. Resume lo que exigen a los equipos que escriben código.

Texto Qué exige Qué se enseña en la auditoría ¿Se exige eficacia?
DORA, art. 13, § 6 Programas de concienciación y formaciones integrados como «módulos obligatorios», para todos los empleados y la dirección, y para los proveedores TIC cuando proceda El programa y su ejecución No
DORA, art. 5, § 4 Formación periódica del órgano de dirección, proporcional al riesgo relacionado con las TIC El seguimiento de las formaciones No
RTS DORA 2024/1774, art. 16 Revisiones de código fuente con pruebas estáticas y dinámicas; código de terceros y de código abierto analizado, en la medida de lo posible, antes de producción Las revisiones, el plan de acción y su seguimiento Indirectamente, por los resultados
PCI DSS 4.0.1, 6.2.2 Formación de los desarrolladores de software a medida al menos una vez cada 12 meses Registros de formación y entrevistas (6.2.2.b) No
PCI DSS 4.0.1, 6.2.3 y 6.2.3.1 Revisión de código antes de producción; en la revisión manual, un revisor distinto del autor Evidencias de las revisiones (6.2.3.b) Indirectamente
NIS2, art. 20, § 2 Los Estados imponen la formación de los órganos de dirección; la del personal se fomenta Según la ley nacional No
NIS2, art. 21, § 2, e a g Seguridad del desarrollo; evaluación de la eficacia de las medidas; formación en ciberseguridad Según la ley nacional Sí, para el conjunto de las medidas
ISO/IEC 27001:2022, 7.2 Competencia del personal y evaluación de la eficacia de las acciones emprendidas Información documentada Sí
AI Act, art. 4, modificado en 2026 Medidas para apoyar la alfabetización en materia de IA, sin nivel garantizado Las medidas adoptadas No

DORA, el reglamento europeo sobre la resiliencia operativa digital del sector financiero, no dice cómo formar ni con qué frecuencia. Su artículo 13 impone programas y formaciones «aplicables a todos los empleados y al personal de alta dirección», con «un nivel de complejidad acorde con las atribuciones de sus funciones». La formación que exige el reglamento DORA es una obligación de organizar módulos, sin ningún resultado que medir.

PCI DSS, la norma de las tarjetas de pago, baja mucho más al detalle. El requisito PCI DSS 6.2.2 fija la frecuencia: al menos una vez cada 12 meses. Fija también el contenido, es decir, la seguridad del software propia de cada función y de cada lenguaje, el diseño y las técnicas de código seguro. Su procedimiento de prueba indica qué mira el evaluador: «Examine training records and interview personnel». Registros y entrevistas.

Estos dos textos describen, por tanto, una formación impartida. ¿Qué ocurre entre el registro y el código?

Sello de tinta sin motivo sobre un montón de hojas de firmas de una formación del reglamento DORA, junto a una pantalla apagada

El sello certifica la asistencia. La pantalla todavía no ha enseñado nada.

Ningún texto pide cruzar el registro con las revisiones de código

Incluso el objetivo que PCI DSS asigna a su requisito de formación se queda en el terreno del conocimiento. En el enfoque personalizado, la norma busca desarrolladores que «remain knowledgeable about secure development practices». Un desarrollador puede estar al día y dejar pasar una vulnerabilidad en una revisión, porque ese día se fijaba en la lógica de negocio.

El artículo 16 del Reglamento Delegado DORA 2024/1774 sí se ocupa del código. Exige «la realización de revisiones de códigos fuente que abarquen pruebas tanto estáticas como dinámicas». Después, las entidades tienen que identificar las vulnerabilidades, adoptar un plan de acción y seguir su aplicación. Esas revisiones generan justo los datos que le faltan al registro de formación, pero nada en el texto pide cruzarlos.

Se podría concluir que el auditor se conforma con el registro y que no tiene sentido ir más allá. Dos textos de la tabla dicen, sin embargo, lo contrario.

Dos textos ya piden evaluar la eficacia

La norma ISO/IEC 27001, en su versión de 2022, trata la competencia en su cláusula 7.2. Según las reproducciones fiables de este texto de pago, pide emprender las acciones necesarias para adquirir la competencia y, después, evaluar su eficacia. También pide conservar información documentada como prueba. Una formación completada es una acción, y su eficacia es otra cuestión, que la norma plantea de forma explícita.

La directiva NIS2 también lo hace, para el conjunto de las medidas de seguridad. Su artículo 21 recoge, en la letra e, la seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas. En la letra g figuran «las prácticas básicas de ciberhigiene y formación en ciberseguridad». Entre ambas, la letra f exige «las políticas y los procedimientos para evaluar la eficacia de las medidas para la gestión de riesgos de ciberseguridad». Yo leo la letra f como aplicable también a la letra g, la formación. Ninguno de los dos textos obliga todavía a todo el mundo. ISO 27001 vale para quien aspira a la certificación, y NIS2 espera su ley francesa.

La guía NIST SP 800-50, en su revisión 1 publicada el 12 de septiembre de 2024, no obliga a nadie. Aun así, propone «suggested metrics and evaluation methods» para hacer evolucionar un programa de formación.

En Francia, el cumplimiento de NIS2 sigue pendiente del texto nacional. El plazo de transposición venció el 17 de octubre de 2024, según InCyber. El proyecto de ley de transposición de NIS2 se examina en la Asamblea Nacional a partir del 7 de octubre de 2026, según Kohen Avocats.

La prueba de eficacia de la formación del reglamento DORA ya está en tus revisiones de código

Mi conclusión es que la materia prima de esa prueba ya existe en las empresas sujetas a DORA o a PCI DSS. Está dormida en las revisiones de código que imponen esos mismos textos. PCI DSS pide evidencias de revisión antes de cada paso a producción, y el RTS DORA, revisiones de código fuente con un plan de acción. Solo falta ponerlas frente al registro de formación.

Esto es lo que yo pondría en el expediente de auditoría, junto al registro:

  • el registro de formación DORA o PCI DSS tal como lo espera el evaluador, con los módulos que ha completado cada desarrollador;
  • los hallazgos de las revisiones de código y de las pruebas de código fuente del mismo periodo, clasificados por tipo de vulnerabilidad;
  • el cruce de ambos: las vulnerabilidades que cubría la formación y las que todavía superan la revisión;
  • el plan de acción resultante y su seguimiento, como pide el artículo 16 del RTS DORA;
  • la misma medición repetida tras cada ciclo de formación, para ver si la curva se mueve.

Ese cruce alimenta la evaluación que piden la cláusula 7.2 de ISO 27001 y la letra f del artículo 21 de NIS2. Sobre todo, le da al comité de dirección algo más que una tasa de finalización. Es también lo que estoy midiendo ahora: lo que los desarrolladores detectan, o dejan pasar, cuando revisan código escrito por una IA. Hablaba de ello en un artículo anterior sobre la revisión de código.

Balanza de dos platillos, con certificados enrollados en uno y una pieza mecánica mecanizada en el otro

A un lado, certificados. Al otro, una pieza que ha cambiado.

Tras un incidente, se mira la segunda columna

Ante los congresistas, Richard Smith describe un protocolo que existía y una alerta que salió al día siguiente. El protocolo preveía incluso un control del efecto, el escáner, y ese control también falló.

Una formación DORA, NIS2 o PCI DSS bien llevada se parece a menudo a ese protocolo. El registro está completo, los módulos están al día y el evaluador se marcha satisfecho. Aun así, yo prepararía la auditoría en dos columnas: lo que se ha hecho y lo que ha cambiado en las revisiones. Tras un incidente, te pedirán la segunda.

Me queda una duda. No sé si los reguladores llegarán a exigir esta prueba de forma explícita, ni si la ley francesa sobre NIS2 lo precisará. Para mí, los dos textos que ya la piden bastan para empezar.

Preguntas frecuentes sobre la formación del reglamento DORA y normas afines

¿Qué obligaciones de formación impone el reglamento DORA?

Las obligaciones del reglamento DORA en materia de formación caben en dos artículos. La formación DORA se rige ante todo por el artículo 13, apartado 6, del reglamento: programas de concienciación sobre seguridad de las TIC y formaciones en resiliencia operativa digital. Se integran en la formación del personal como «módulos obligatorios», para todos los empleados y la dirección. El artículo 5 añade una formación periódica para el órgano de dirección. El texto no fija ni frecuencia ni duración.

Requisito 6.2.2 de PCI DSS: ¿qué dice?

PCI DSS 4.0.1 exige que los desarrolladores de software a medida reciban formación «at least once every 12 months». La formación trata la seguridad del software propia de su función y de sus lenguajes, incluidos el diseño y las técnicas de código seguro. Para comprobarlo, el evaluador examina los registros de formación y entrevista al personal, según el procedimiento 6.2.2.b.

¿Cuándo entra en vigor NIS2 en Francia?

La directiva NIS2 tenía que transponerse antes del 17 de octubre de 2024. En Francia, el proyecto de ley de transposición se examina en la Asamblea Nacional a partir del 7 de octubre de 2026, según Kohen Avocats. Las obligaciones nacionales, formación incluida, dependerán del texto que se apruebe. La directiva obliga a cada Estado a imponer esa formación a los órganos de dirección. En Francia, por tanto, la obligación espera a la ley.

¿Qué dice el artículo 4 de la AI Act?

En su versión de 2024, el artículo 4 de la AI Act se dirigía a los proveedores y a los responsables del despliegue de sistemas de IA. Debían garantizar «en la mayor medida posible, […] un nivel suficiente de alfabetización en materia de IA» de su personal. Desde que el reglamento Omnibus entró en vigor el 27 de julio de 2026, les pide apoyar esa alfabetización, sin garantizar ningún nivel, según Law & Technology.

Fuentes