[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:es:que-partes-de-su-backend-estan-dentro-del-cra-tratamiento-remoto-de-datos":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"es","que-partes-de-su-backend-estan-dentro-del-cra-tratamiento-remoto-de-datos","¿Qué partes de su backend están dentro del CRA? El tratamiento remoto de datos, según las orientaciones de la Comisión","Un producto con elementos digitales incluye sus soluciones de tratamiento remoto de datos, y el Reglamento las define en una frase. Las orientaciones de la Comisión del 27 de julio de 2026 convierten esa frase en dos pruebas acumulativas, una regla de delimitación, una lista de lo que nunca entra (CI\u002FCD, RR. HH., CRM, telemetría, sitios web), los casos SaaS, PaaS e IaaS, y un ejemplo de banca móvil resuelto de principio a fin. Para una empresa de software con una app y una nube, esta es la línea.","2026-09-11","\nEl artículo 3(1) del Cyber Resilience Act, Reglamento (UE) 2024\u002F2847, define un producto con elementos digitales como «un producto de software o hardware y sus soluciones de tratamiento remoto de datos». El artículo 3(2) define el tratamiento remoto de datos como «tratamiento de datos a distancia para el que el software ha sido diseñado y desarrollado por el fabricante, o bajo la responsabilidad del fabricante, y sin el cual el producto con elementos digitales no podría realizar una de sus funciones». [Que su producto esté dentro del ámbito](\u002Farticles\u002Fis-your-product-in-scope-of-the-cyber-resilience-act) depende del artículo 2 y del considerando 12. Una vez que lo está, la siguiente pregunta para toda empresa con una app y una nube es qué partes de la nube han entrado con él, porque esas partes van a la evaluación de riesgos, a los requisitos esenciales, a la documentación técnica y a la obligación de notificación.\n\nLas orientaciones de la Comisión sobre la aplicación del Reglamento, C(2026) 5252 de 27 de julio de 2026, sección 8, apartados 178 a 208, responden a esa pregunta con más precisión que el Reglamento. Este artículo es esa sección, con sus cinco casos de uso, leída para un fabricante de software.\n\n## Dos pruebas acumulativas\n\nEl apartado 184 descompone la definición en tres elementos: si el tratamiento es a distancia, si su ausencia impediría al producto realizar una de sus funciones, y si el software fue diseñado y desarrollado por el fabricante o bajo su responsabilidad. El apartado 185 deja después el primero a un lado como «pertinente pero no suficiente»: la nube, el edge y los propios servidores locales del fabricante cuentan todos como a distancia (apartado 187), así que el primer elemento rara vez decide nada. El apartado 188 enuncia la regla: el segundo y el tercero son «las dos preguntas decisivas y acumulativas», y «si ambas preguntas se responden afirmativamente, el tratamiento remoto de datos se considera» solución de tratamiento remoto de datos.\n\nEl apartado 202 da los tres resultados. Ambos sí: forma parte de su producto, y el anexo I se le aplica. La prueba de la función no: no forma parte del producto, pero «los fabricantes deben evaluar los riesgos derivados de la existencia de ese tratamiento de datos como parte de su evaluación de riesgos». La prueba de la función sí pero la de la responsabilidad no: «los fabricantes deben tratar la solución de terceros como un componente», evaluar y mitigar los riesgos de integrarla, y «ejercer la diligencia debida».\n\n## Prueba uno: ¿su ausencia detendría una función?\n\nLa palabra es «funciones», no funcionalidad principal. Apartado 189: «la noción de \"funciones\" incluida en esta definición no se limita a la \"funcionalidad principal\" o la \"finalidad prevista\" del producto con elementos digitales», y abarca «tanto las funciones que cumplen directamente la finalidad prevista del producto con elementos digitales tal como la experimentan los usuarios como las funciones que sustentan el rendimiento general del producto». El apartado 190 enumera seis ejemplos de tratamiento a distancia sin los que un producto no puede pasar: «(i) enviar órdenes a un dispositivo; (ii) sincronizar archivos; (iii) incorporar al usuario; (iv) configuración (personalización del producto con elementos digitales); (v) distribución automatizada de actualizaciones, incluidas las de funcionalidad y los parches de seguridad; (vi) gestión de identidades y accesos».\n\nDos matices importan para el software. Una función que el usuario puede realizar tanto a distancia como manualmente, la bombilla encendida desde una app o a mano, cuenta igualmente: «realizar esta función a distancia también se considera parte de las funciones que ofrece el producto con elementos digitales» (apartado 191). Y el contraejemplo es la telemetría: «el análisis remoto de datos de telemetría recogidos con fines puramente estadísticos o para el desarrollo futuro del producto» no es una función que el producto necesite, así que no es tratamiento remoto de datos (apartado 192), aunque el apartado 193 añade que los riesgos de esos componentes remotos siguen perteneciendo a la evaluación de riesgos.\n\nLos sitios web tienen su propio apartado, el 194. Un sitio que solo lleva información sobre el producto no entra, «aunque el producto redirija a ese sitio». Un sitio que «permite o sustenta una función» sí: «un portal de autenticación que emite credenciales o tokens necesarios para que el producto con elementos digitales funcione se consideraría una RDPS». Para la mayoría de las empresas de software, esa única frase coloca el servicio de inicio de sesión dentro del producto.\n\n## Prueba dos: diseñado y desarrollado por usted, o bajo su responsabilidad\n\nApartado 195: el software construido en casa cumple, y también el que un proveedor externo construye para usted, pero «bajo la responsabilidad del fabricante» significa «a medida para el fabricante», casos en los que «el software se construye únicamente por el fabricante o por cuenta de él, sobre la base de diseños y especificaciones facilitados por él». Licenciar un servicio existente, «o versiones ligeramente modificadas del mismo», no es eso.\n\nQuién lo opera es irrelevante. Apartado 196: «la noción de \"quién opera la solución\" no es un factor decisivo, ya que la definición del CRA solo se refiere al diseño y el desarrollo». Un backend que usted escribió y que opera una empresa de alojamiento es suyo.\n\nLos apartados 197 a 200 clasifican después los tres modelos de nube. En una **IaaS** de terceros, usted despliega sus propios sistemas operativos y aplicaciones; ese software «es diseñado y desarrollado por el fabricante, o bajo su responsabilidad, y por tanto puede considerarse» (apartado 198). En una **PaaS** de terceros, usted despliega su propia aplicación sobre el entorno de ejecución del proveedor; «la aplicación es, por tanto, diseñada y desarrollada por el fabricante» y puede considerarse (apartado 199). Una aplicación **SaaS** de terceros integrada en su producto «no es, por tanto, diseñada y desarrollada por el fabricante» (apartado 200) y no es tratamiento remoto de datos, cualquiera que sea la función que sustente.\n\nLo que queda fuera de la definición no queda fuera de su responsabilidad. Apartado 201: el hipervisor bajo su IaaS, el sistema operativo bajo su PaaS, el SaaS de terceros «deben considerarse similares a componentes de terceros» donde afecten a la seguridad del producto, y el fabricante «está obligado a identificar y evaluar los riesgos vinculados a la integración de esos elementos y a abordarlos aplicando los requisitos esenciales en el propio producto con elementos digitales», ejerciendo «una obligación similar a la de diligencia debida a que se refiere el artículo 13(5)».\n\n## El límite: los módulos con los que habla su producto, no todo lo que hay detrás\n\nEsta es la parte que decide cuánto crece la documentación técnica. Apartado 205: el tratamiento remoto de datos sujeto a la evaluación de la conformidad del producto «debe limitarse a los módulos de software responsables de la funcionalidad del producto con elementos digitales, y a las interfaces que esos módulos usan con servicios externos. Los demás sistemas back-end que realizan un tratamiento posterior, y con los que el producto con elementos digitales no interactúa directamente, no se consideran RDPS». El apartado 206 los mantiene en la evaluación de riesgos como «dependencias externas que deben evaluarse» y mitigarse «mediante medidas a nivel de producto».\n\nEl apartado 182 enumera lo que la definición nunca pretendió alcanzar, apoyándose en el considerando 11: «los sistemas internos relativos a los recursos humanos del propio fabricante, las nóminas, la gestión de relaciones con clientes, las canalizaciones de integración continua\u002Fentrega continua (CI\u002FCD), la distribución de actualizaciones de seguridad a ubicaciones periféricas, no deben considerarse RDPS», y tampoco «los sistemas vinculados a actividades de auditoría y prueba, como las pruebas de penetración, la caza de amenazas y el red teaming». El CRA cubre el producto, no «toda la infraestructura informática de una organización». Ese es el territorio de NIS2, y el considerando 12 lo dice.\n\n## El caso de la banca móvil, que es el de la mayoría de las empresas de software\n\nLa sección 8.3.1 recorre la app de un banco con un backend autoalojado y un chat de soporte de terceros. La app habla con una «interfaz bancaria» que el banco construyó, que a su vez consulta un sistema de gestión de cuentas y un libro mayor. La interfaz autentica al cliente, envía órdenes de transferencia y devuelve su estado; «es necesaria para que la app realice sus funciones» y «está diseñada y desarrollada bajo la responsabilidad del fabricante», así que es tratamiento remoto de datos y «debe incluirse, por tanto, en la evaluación de riesgos de ciberseguridad y en la aplicación de los requisitos esenciales». El sistema de gestión de cuentas y el libro mayor no lo son: «la app no interactúa directamente con ellos», y «aunque su disponibilidad pueda ser necesaria para completar una función, el CRA solo cubre las partes del sistema que interactúan directamente con el producto». Siguen siendo dependencias externas cuyo compromiso «podría permitir a un atacante influir en los resultados de las transacciones», a mitigar a nivel de producto, «como la autenticación fuerte de las interfaces back-end, la protección de la integridad de los datos de las transacciones, canales de comunicación seguros y la verificación de las respuestas recibidas por la app».\n\nEl chat de soporte, «desarrollado y operado por un proveedor tercero», es necesario para una función pero no supera la prueba de la responsabilidad, así que «no es una RDPS» y «debe tratarse como un componente de terceros», aislado de las funciones principales, con diligencia debida sobre el proveedor.\n\nTraslade eso a un SaaS B2B típico con un cliente de escritorio o móvil: la pasarela de API y el servicio de autenticación que llama el cliente están en el producto; el almacén de datos tres saltos por detrás es una dependencia externa; los widgets de analítica, chat o pagos de terceros incrustados son componentes. Los otros cuatro casos confirman el patrón: las funciones en la nube de un termostato sobre IaaS de terceros están dentro (8.3.2), el almacenamiento SaaS de terceros de un lector electrónico es un componente (8.3.3), el servicio de visión de un robot sobre IaaS está dentro (8.3.4), y la red 5G de un teléfono no es ninguna de las dos cosas, «solo un canal de comunicación», sin diligencia debida hacia el operador (8.3.5).\n\n## Qué va en el expediente, y qué puede reutilizar\n\nApartado 204: los fabricantes «deben (i) indicar en la documentación técnica que su producto con elementos digitales tiene RDPS o depende de soluciones remotas de terceros y (ii) describir esas soluciones», y cuando un mismo backend sirve a varios productos, se declara en el expediente de cada producto y la documentación «puede reutilizarse de una evaluación de la conformidad a otra».\n\nPara los servicios de terceros de los que depende, el apartado 207 enumera los elementos de garantía que pueden reutilizarse en apoyo de su evaluación y su diligencia debida: pruebas del cumplimiento por el proveedor del reglamento de ejecución de NIS2, de DORA, un certificado obtenido bajo un esquema europeo de certificación de ciberseguridad, o «pruebas de conformidad con ISO\u002FIEC 27017:2015 o ISO\u002FIEC 27001:2022». El apartado 208 añade el lado contractual: garantías de seguridad en los acuerdos de nivel de servicio, «incluidas garantías de que los proveedores gestionan adecuadamente las vulnerabilidades», y un cambio importante en un proveedor no es una modificación sustancial de su producto, pero puede exigir revisar su evaluación de riesgos.\n\nLeído desde el otro lado, el apartado 207(d) es también lo que sus propios clientes pueden pedirle. Si su producto es tratamiento remoto de datos para el suyo, su certificado ISO 27001 es el elemento que las orientaciones nombran para el expediente de ellos.\n\n## La determinación, en seis líneas\n\nPara cada servicio remoto que llame su producto, registre:\n\n1. El servicio y la función que sustenta, en el sentido que las orientaciones dan a función.\n2. Prueba uno: ¿perdería el producto esa función sin él? Telemetría y sitios web informativos: no.\n3. Prueba dos: construido por usted o según su especificación, o aplicación de terceros bajo licencia. IaaS y PaaS ponen su código en el lado de dentro; SaaS pone la aplicación en el lado de los componentes.\n4. El resultado según el apartado 202: parte del producto, componente a evaluar con diligencia debida, o dependencia externa a evaluar.\n5. El límite según el apartado 205: con qué módulos interactúa directamente el producto, y qué sistemas quedan detrás.\n6. El elemento que posee para cada servicio de terceros, de la lista del apartado 207, y la fecha en que lo obtuvo.\n\nEsa tabla es la sección de tratamiento remoto de la documentación técnica, la entrada de [la evaluación de riesgos que exige el artículo 13](\u002Farticles\u002Fthe-cra-cybersecurity-risk-assessment-what-article-13-actually-requires), y la respuesta a la segunda pregunta de [nuestra determinación del ámbito](\u002Fcyber-resilience-act\u002Fscope). Es también la lista de sistemas cuyo compromiso pone en marcha [el reloj de notificación](\u002Farticles\u002Fwhen-does-the-cra-24-hour-clock-start-becoming-aware), porque el apartado 178 dice que el producto, tratamiento remoto incluido, es aquello sobre lo que informa el artículo 14.\n\n## Fuentes\n\n- Reglamento (UE) 2024\u002F2847, artículo 3(1), (2) y (4), artículo 13(2), (3) y (5), considerandos 11 y 12.\n- Comisión Europea, orientaciones de la Comisión sobre la aplicación del Reglamento (UE) 2024\u002F2847, C(2026) 5252 final de 27 de julio de 2026, anexo, sección 8, apartados 178 a 208 y casos de uso 8.3.1 a 8.3.5.\n- Directiva (UE) 2022\u002F2555 (NIS2) y Reglamento de Ejecución (UE) 2024\u002F2690 de la Comisión, para los servicios en la nube que las orientaciones les dejan.\n\nEsto no es asesoramiento jurídico. La sección 8 son once páginas y los cinco casos son la parte más clara de todas las orientaciones; léalos antes de trazar su propia línea.\n",1789383977254]