DORA, para un proveedor de software

DORA para un proveedor de software: las cláusulas contractuales del artículo 30 que le enviará su cliente bancario, el registro de información en el que figurará, y lo que ISO 27001 ya responde

Desde el 17 de enero de 2025, todo banco, aseguradora, empresa de servicios de inversión y entidad de pago de la Unión gestiona a sus proveedores de software con arreglo al Reglamento (UE) 2022/2554, DORA. El proveedor no está regulado; el contrato sí. El artículo 30 enumera nueve cláusulas que todo contrato de servicios de TIC debe contener y seis más cuando el servicio sustenta una función esencial o importante: ubicaciones, devolución de datos, asistencia en incidentes a un coste fijado de antemano, cooperación con las autoridades del cliente, preaviso de resolución, derechos de auditoría, estrategias de salida. Cada cláusula leída en el Reglamento, el registro de información que el cliente presenta cada año, los tres actos delegados que hay detrás, y para cuáles de esas cláusulas un sistema ISO 27001 ya produce la evidencia.

Los diecinueve tipos de servicios de TIC de DORA, S01 a S19: cuál es un producto SaaS, qué consigna el registro de información sobre él, y por qué un contrato puede ser varias filas

Cada servicio de TIC que compra un banco, una aseguradora o una entidad de pago se consigna en su registro de información bajo uno de diecinueve códigos, S01 a S19, del anexo III del Reglamento de Ejecución (UE) 2024/2956. Un producto alojado es S19, el software instalado S13, un servicio gestionado S14, un feed de datos S05, y el cliente presenta una fila por servicio y función, de modo que un solo contrato puede convertirse en varias. Los diecinueve tipos con las descripciones del propio Reglamento, la columna que lleva el código, lo que el cliente debe consignar al lado, y por qué el código que da a un cliente debe coincidir con el que da al siguiente.

La subcontratación bajo DORA, RTS 2025/532: las doce condiciones que lleva su contrato cuando subcontrata un servicio esencial, las diez condiciones que su cliente comprueba antes, y el plazo de preaviso antes de cambiar de subcontratista

Desde el 22 de julio de 2025 una entidad financiera solo puede permitir que su proveedor de software subcontrate un servicio que sustenta una función esencial o importante en las condiciones del Reglamento Delegado (UE) 2025/532. Diez condiciones que el cliente evalúa antes de firmar, desde su capacidad para identificar a cada subcontratista hasta si el subcontratista concede los mismos derechos de auditoría; doce condiciones que el contrato lleva después, desde su responsabilidad por el servicio del subcontratista hasta el derecho de resolución del cliente; un plazo durante el cual no puede cambiar de subcontratista hasta que el cliente haya aprobado o no se haya opuesto; y tres casos en los que el cliente puede resolver el contrato. Leído en el Diario Oficial, con lo que el registro de información consigna sobre la cadena y lo que un registro de proveedores ISO 27001 ya responde.

La política DORA de su banco sobre proveedores, RTS 2024/1773: las seis preguntas de la diligencia debida, las cinco fuentes de garantía, las ocho condiciones para aceptar su certificado ISO 27001 en lugar de una auditoría, y los cinco informes que deberá

Toda entidad financiera de la Unión tiene una política escrita sobre sus contratos de servicios de TIC que sustentan funciones esenciales o importantes, y el Reglamento Delegado (UE) 2024/1773 dice qué debe contener esa política, en vigor desde el 15 de julio de 2024. Leído desde el lado del proveedor: las seis cosas que el cliente evalúa sobre usted antes de firmar (artículo 6), las cinco fuentes de garantía que puede usar y las ocho condiciones bajo las cuales puede confiar en sus certificaciones o informes de auditoría en vez de auditarle él mismo (artículo 8), los indicadores clave, las penalizaciones y los cinco tipos de informe que exigirá el contrato (artículo 9), y el plan de salida que debe probar (artículo 10). Con lo que un certificado ISO 27001 responde, y lo que no.

Cuando su caída se convierte en el incidente grave de su cliente bancario: los seis criterios de DORA, el umbral de dos horas de inactividad del RTS 2024/1772, los plazos de cuatro horas, 24 horas, 72 horas y un mes del RTS 2025/301, y los datos que su cliente necesitará de usted

Una entidad financiera debe notificar un incidente grave relacionado con las TIC a su supervisor en las cuatro horas siguientes a su clasificación y a más tardar 24 horas después de tener conocimiento de él, presentar un informe intermedio en 72 horas y cerrar en un mes. Que una caída en su proveedor de software sea grave lo deciden seis criterios y los umbrales del Reglamento Delegado (UE) 2024/1772: más de dos horas de inactividad de un servicio que sustenta una función esencial o importante, más de 24 horas de duración, más del 10 por ciento de los clientes, dos o más Estados miembros, pérdidas de datos, 100 000 euros. Lo que debe contener cada informe según el Reglamento Delegado (UE) 2025/301, cuáles de esos datos solo tiene el proveedor, y en qué convierte eso la cláusula de asistencia en caso de incidente del artículo 30, apartado 2, letra f). Leído en el Diario Oficial.

Los nueve lugares en los que el marco de riesgos de TIC de su cliente bancario entra en su producto, RTS 2024/1774: fechas de fin de soporte, informes de vulnerabilidades y seguimiento de bibliotecas, ajustes que no puede eludir, código fuente probado antes de producción, cuentas nominales para su personal, y sus incidentes como sus alarmas

El Reglamento Delegado (UE) 2024/1774, en vigor desde el 15 de julio de 2024, especifica el marco de gestión del riesgo relacionado con las TIC que toda entidad financiera aplica bajo DORA, y nueve de sus artículos nombran al proveedor tercero de servicios de TIC. Leído desde el lado del proveedor: el registro de activos que consigna las fechas de fin de su soporte (artículo 4), el procedimiento de vulnerabilidades que verifica que usted gestiona y notifica vulnerabilidades y sigue las bibliotecas de terceros de su producto (artículo 10), el procedimiento de seguridad de datos y sistemas que reparte funciones entre usted y el cliente y pide medidas sobre su infraestructura (artículo 11), conexiones cifradas sobre redes de terceros (artículo 13), código fuente de proveedores analizado y probado antes de producción (artículo 16), una cuenta única para cada miembro de su personal con acceso (artículo 20), sus notificaciones de incidentes como una de sus fuentes de detección (artículo 23), pruebas de continuidad que incluyen su servicio y su insolvencia (artículos 25 y 26). Con lo que un sistema ISO 27001 ya responde.

Las pruebas de penetración guiadas por amenazas bajo DORA, desde el lado del proveedor: cuándo el equipo rojo de su cliente bancario puede entrar en sus sistemas de producción, la prueba de 12 semanas del RTS 2025/1190, la prueba agrupada que puede realizar en su lugar, y lo que el contrato ya dice

El artículo 26 de DORA hace que las mayores entidades financieras realicen una prueba de penetración guiada por amenazas sobre sistemas de producción al menos cada 3 años, que cubre las funciones esenciales o importantes que han externalizado, y el artículo 30, apartado 3, letra d), pone la participación del proveedor en el contrato. El Reglamento Delegado (UE) 2025/1190, en vigor desde el 8 de julio de 2025, fija la mecánica: un equipo de control que puede incluir a su personal, un equipo azul que no debe saber, una fase activa de equipo rojo de al menos 12 semanas, una repetición y un ejercicio morado en las 10 semanas siguientes a su fin, un plan de corrección en 8 semanas. El artículo 26, apartado 4, permite a un proveedor cuyos otros clientes saldrían perjudicados contratar directamente a un probador externo y realizar una sola prueba agrupada para varias entidades financieras. Lo que el proveedor firma, lo que puede rechazar, y lo que un sistema ISO 27001 ya contiene. Leído en el Diario Oficial.

ISO 27001 vs SOC 2 en Europa: qué piden realmente los compradores

Si vende en Europa, consiga ISO 27001: las licitaciones públicas de la UE la mencionaron 3.408 veces en un año, frente a 104 de SOC 2. Si vende a clientes estadounidenses, es al revés. Las cifras, la consulta pública de TED para repetirlas, y cuándo necesita ambas.

¿CRA o NIS2? Cuál se aplica a una empresa de software, y si pueden ser las dos

El Reglamento de Ciberresiliencia regula productos introducidos en el mercado; NIS2 regula entidades que prestan servicios. Una empresa de software puede estar bajo una, la otra, ambas o ninguna, y la respuesta depende de dos preguntas: si introduce un producto en el mercado y si es una entidad mediana o mayor en un sector listado. Las fechas, los relojes de notificación, las multas y la tabla de decisión, a partir de los dos textos.