El artículo 28, apartado 1, del Reglamento (UE) 2022/2554, DORA, convierte el marco de gestión del riesgo relacionado con las TIC del cliente en aquello de lo que su servicio es un componente, y el Reglamento Delegado (UE) 2024/1774 de la Comisión, de 13 de marzo de 2024, publicado el 25 de junio de 2024 y en vigor desde el 15 de julio de 2024, especifica ese marco en cuarenta y dos artículos: las políticas, procedimientos, protocolos y herramientas del artículo 9, apartado 2, de DORA, los mecanismos de detección del artículo 10, los planes de continuidad y recuperación del artículo 11, y un marco simplificado para las entidades pequeñas del artículo 16. La mayor parte es la gestión interna del propio cliente. Nueve artículos nombran al proveedor tercero de servicios de TIC, y cada uno es una pregunta que el marco del cliente tiene que poder responder sobre usted, es decir, una pregunta que le harán. Este artículo lee esos nueve en el Diario Oficial en CELLAR el 12 de septiembre de 2026, desde el lado del proveedor. No es asesoramiento jurídico.
El registro de activos quiere sus fechas de fin de soporte, artículo 4
El artículo 4 exige una política de gestión de activos de TIC conforme a la cual la entidad mantiene registros de cada activo de TIC: un identificador único, su ubicación física o lógica, su clasificación, su propietario, las funciones de negocio que sustenta, sus requisitos de continuidad, incluidos los objetivos de tiempo y de punto de recuperación, si está expuesto a redes externas, sus vínculos e interdependencias con otros activos y, letra b), inciso ix), del apartado 2, cuando proceda, las fechas de fin de los servicios de soporte regulares, ampliados y a medida del proveedor tercero de servicios de TIC, tras las cuales el activo deja de estar soportado. Para un proveedor eso significa un ciclo de vida de soporte publicado por versión de producto, con fechas, porque el registro del cliente tiene una columna para ello y una columna vacía es un hallazgo en la próxima auditoría del cliente.
El procedimiento de vulnerabilidades le verifica a usted, y sigue sus bibliotecas, artículo 10
El artículo 10 exige procedimientos de gestión de vulnerabilidades que, entre otras cosas, verifiquen si los proveedores terceros de servicios de TIC gestionan las vulnerabilidades relacionadas con los servicios que prestan y si notifican a la entidad al menos las vulnerabilidades críticas y estadísticas y tendencias con puntualidad; y que hagan un seguimiento del uso de bibliotecas de terceros, incluidas las de código abierto, utilizadas por los servicios que sustentan funciones esenciales o importantes, y de los servicios desarrollados o personalizados para la entidad por un proveedor. El Reglamento añade que la entidad pide a los proveedores que investiguen las vulnerabilidades pertinentes, determinen las causas raíz y apliquen medidas de mitigación, y que supervisa las versiones y actualizaciones de las bibliotecas de terceros, cuando proceda en colaboración con el proveedor. La propia entidad ejecuta análisis automatizados de vulnerabilidades al menos semanalmente sobre los activos que sustentan funciones esenciales o importantes, y su gestión de parches fija plazos con escalado.
Leído desde el lado del proveedor, son tres entregables: un proceso de gestión de vulnerabilidades cuya existencia el cliente puede verificar, un informe periódico de vulnerabilidades que nombre al menos las críticas con estadísticas y tendencias, y una lista de los componentes de terceros y de código abierto del producto con sus versiones, es decir, la lista de materiales de software que el Reglamento de Ciberresiliencia exige a un fabricante por sus propias razones. Un proveedor que ya la produce para el CRA responde al artículo 10, apartado 2, letra d), con el mismo documento.
Seguridad de datos y sistemas: funciones entre usted y el cliente, medidas sobre su infraestructura, artículo 11
El artículo 11 exige un procedimiento de seguridad de datos y sistemas cuyos elementos incluyen, para los activos o servicios de TIC operados por un proveedor tercero de servicios de TIC, letra k), la identificación y aplicación de requisitos para mantener la resiliencia operativa digital de acuerdo con la clasificación de datos y la evaluación del riesgo relacionado con las TIC. Para ese punto la entidad considera la aplicación de la configuración recomendada por el proveedor en los elementos que ella misma opera, una asignación clara de las funciones y responsabilidades de seguridad de la información entre la entidad y el proveedor, conforme a la plena responsabilidad de la entidad en virtud del artículo 28, apartado 1, letra a), de DORA, las competencias que necesita para gestionar y asegurar el servicio, y medidas técnicas y organizativas para minimizar los riesgos relacionados con la infraestructura que el proveedor usa para sus servicios, considerando las mejores prácticas y las normas. La letra f), inciso ii), del mismo artículo, sobre dispositivos finales, exige mecanismos de seguridad que no puedan ser modificados, eliminados ni eludidos por el personal ni por los proveedores terceros de servicios de TIC de forma no autorizada.
Para un proveedor SaaS la asignación de funciones es el documento de responsabilidad compartida: qué ajustes de seguridad configura el cliente, cuáles opera el proveedor y cuáles el cliente no puede desactivar. Las medidas sobre su infraestructura son los controles que describe el alcance de su certificado, y el marco del cliente los pedirá por referencia a una norma.
Conexiones cifradas sobre redes de terceros, artículo 13
El artículo 13 exige medidas de seguridad de red que incluyan el cifrado de las conexiones de red que pasan por redes corporativas, públicas, domésticas, de terceros e inalámbricas, para los protocolos de comunicación usados, teniendo en cuenta la clasificación de datos, y, para los servicios de red de la entidad, la documentación de si los presta un proveedor intragrupo o proveedores terceros. La respuesta del proveedor es el cifrado en tránsito de cada conexión entre el cliente y el producto y entre el producto y sus subcontratistas, con las versiones de protocolo por escrito.
El código fuente de los proveedores se analiza y prueba antes de producción, artículo 16
El artículo 16 exige una política de adquisición, desarrollo y mantenimiento de sistemas de TIC, y un procedimiento de prueba y aprobación de todos los sistemas de TIC antes de su uso y tras el mantenimiento, proporcional a la criticidad de los procesos de negocio y activos afectados. El procedimiento contiene controles para proteger la integridad del código fuente desarrollado internamente o por un proveedor y entregado a la entidad, y prevé que el software propietario y, cuando sea viable, el código fuente proporcionado por proveedores terceros o procedente de proyectos de código abierto se analicen y prueben antes de su despliegue en producción. Para un proveedor cuyo producto instala el cliente, eso es el derecho del cliente a probar su versión antes de ponerla en marcha y a ver controles de integridad sobre lo que usted entrega: versiones firmadas, sumas de comprobación, una cadena de compilación que pueda describir. Para un proveedor SaaS es el interés del cliente en sus propias pruebas de versión, porque el despliegue en producción ocurre de su lado.
Una cuenta nominal para cada miembro de su personal con acceso, artículo 20
El artículo 20 exige políticas de gestión de identidades conforme a las cuales se asigna una identidad única correspondiente a una cuenta de usuario única a cada miembro del personal de la entidad o de un proveedor tercero de servicios de TIC que acceda a los activos de información y de TIC de la entidad. Cuando su personal de soporte entra en el entorno del cliente, el cliente le expedirá cuentas nominales y esperará que usted le diga quién se incorpora y quién se va; cuando solo entra en su propio entorno, el cuestionario del cliente le pedirá mostrar la misma regla aplicada en casa.
Sus notificaciones de incidentes son una de las fuentes de detección del cliente, artículo 23
El artículo 23 exige un mecanismo para detectar con prontitud actividades anómalas que recoja, supervise y analice, entre otras fuentes, las notificaciones de incidentes relacionados con las TIC de un proveedor tercero de servicios de TIC, detectados en los sistemas y redes propios del proveedor, que puedan afectar a la entidad. La alerta del cliente está diseñada para recibir sus notificaciones como un flujo, junto a sus propios registros e inteligencia sobre amenazas, y para priorizarlas de modo que se gestionen dentro de su tiempo de resolución esperado, durante y fuera del horario laboral. El artículo sobre incidentes graves explica lo que ocurre después: el plazo de cuatro horas en el cliente empieza cuando clasifica, y su notificación es lo que le permite clasificar.
Las pruebas de continuidad incluyen su servicio y su insolvencia, artículos 25 y 26
El artículo 25 exige que las pruebas de los planes de continuidad de la actividad de TIC de la entidad contengan, cuando proceda, la prueba de los servicios de TIC prestados por proveedores terceros, y procedimientos para verificar que el personal de la entidad, sus proveedores, sus sistemas y sus servicios pueden responder adecuadamente a los escenarios del artículo 26; para los escenarios de proveedores la entidad tiene debidamente en cuenta la insolvencia o el fallo del proveedor y los riesgos políticos en la jurisdicción del proveedor. El artículo 26 exige que los planes de respuesta y recuperación consideren escenarios en los que una función esencial o importante se deteriora o falla, con el impacto potencial de la insolvencia u otro fallo de un proveedor, y la inestabilidad política y social en la jurisdicción del proveedor y donde se almacenan y tratan los datos, y que se apliquen medidas de continuidad para mitigar los fallos de los proveedores de servicios que sustentan funciones esenciales o importantes. La parte del proveedor es el procedimiento de salida y transición de la lista de cláusulas del artículo 30, 30(3)(f), y su disposición a participar en la prueba de continuidad del cliente, que la letra c) del artículo 30, apartado 3, ya pone en el contrato.
Lo que un sistema ISO 27001 ya responde
El Reglamento Delegado no nombra ninguna norma, y lo que sigue es la lectura de StandardOS de dónde produce las respuestas un sistema de gestión ISO/IEC 27001:2022, sin presunción de conformidad. El artículo 4, apartado 2, letra b), inciso ix), es el inventario de activos, A.5.9, si el inventario lleva fechas de fin de soporte. El artículo 10 es el control de gestión de vulnerabilidades, A.8.8, y las condiciones de notificación de los proveedores de A.5.20; la lista de componentes es el mismo registro que pide el CRA. El artículo 11, letra k), es el acuerdo con el proveedor, A.5.20, y el control de configuración, A.8.9; la letra f), inciso ii), es A.8.1 y A.8.7. El artículo 13 es A.8.20 a A.8.22 y el control de criptografía, A.8.24. El artículo 16 es el desarrollo seguro, A.8.25 a A.8.29, con las pruebas de versión de A.8.29 y la gestión de cambios de A.8.32. El artículo 20 es A.5.16, gestión de identidades, y A.5.18, derechos de acceso. El artículo 23 es la planificación de la gestión de incidentes de A.5.24 y el registro y la supervisión de A.8.15 y A.8.16, de donde sale la notificación. Los artículos 25 y 26 son A.5.29 y A.5.30 y las pruebas de continuidad que exigen. Lo que la norma no le da son el registro del cliente, su clasificación de su servicio y sus escenarios; esas son preguntas que usted responde con hechos, y la ficha de datos del registro contiene los relativos a ubicaciones y subcontratistas.
Qué hacer antes de que lleguen las preguntas del marco
Publique un ciclo de vida de soporte con fechas por versión. Produzca una lista de componentes con versiones y un informe periódico de vulnerabilidades, y escriba la cadencia de notificación en el contrato. Redacte el documento de responsabilidad compartida que reparte las funciones conforme al artículo 11, letra k), incluidos los ajustes que el cliente no puede desactivar. Documente el cifrado en tránsito con las versiones de protocolo. Describa la cadena de publicación y sus controles de integridad. Aplique cuentas nominales a su propio personal y ofrezca el aviso de altas y bajas para las cuentas en el entorno del cliente. Conecte sus notificaciones de incidentes a un canal que el cliente pueda ingerir. Y ensaye la salida con el cliente cuando lo pida, porque el artículo 25 dice que lo hará. El centro DORA reúne las fechas del Reglamento y de sus actos.