Cyber Resilience Act · 2026/2027

CRA para SaaS: alcance, acciones propias y evidencia

Autor: Piotr AdamskiRevisión operativa y de seguridad: Brillnet C-Team

Contenido informativo. No sustituye asesoramiento jurídico individual ni evaluación de conformidad.

Comprueba el ámbito CRA y descarga tu evaluación

No hay respuesta segura a «¿SaaS está incluido en CRA?» solo a partir del modelo de suscripción. CRA regula productos con elementos digitales; el marco NIS2 también aborda servicios de computación en nube, incluido SaaS. La pregunta clave es qué es el producto, qué software se comercializa y si un servicio remoto es parte integral de una función del producto.

Empieza por arquitectura y modelo de entrega, no por la etiqueta comercial.

Dos preguntas que suelen mezclarse

¿El propio servicio de nube es un producto con elementos digitales según CRA?

No lo supongas simplemente porque el usuario accede por navegador.

¿El servicio remoto forma parte de otro producto con elementos digitales?

Puede ser. CRA define una «solución de tratamiento de datos a distancia» como tratamiento remoto cuyo software diseña y desarrolla el fabricante o se desarrolla bajo su responsabilidad y cuya ausencia impediría al producto desempeñar una función.

Los considerandos CRA dan un ejemplo de aplicación móvil que necesita una API o base de datos suministrada mediante servicio desarrollado por el fabricante. En esa situación, puede quedar dentro del ámbito del producto como solución de tratamiento a distancia.

Mapea arquitectura antes de decidir el ámbito

Para una oferta SaaS, describe por separado:

  1. software entregado al cliente: agente, aplicación de escritorio/móvil, equipo dedicado, extensión, biblioteca;
  2. interfaz web: lo que utiliza el usuario en el navegador;
  3. backend/API: funciones ejecutadas remotamente;
  4. bases de datos y tratamiento: elementos remotos necesarios para funciones del producto;
  5. integraciones de terceros: qué está bajo responsabilidad del fabricante y qué no;
  6. modelo de mercado: quién comercializa y con qué marca;
  7. actualizaciones: qué cambia el fabricante y cómo afecta a seguridad;
  8. soporte: cuánto se mantiene cada componente pertinente.

El mapa apoya tanto evaluación de ámbito como documentación técnica posterior.

Tres situaciones de ejemplo

A. Servicio de nube solo por navegador

El usuario inicia sesión por navegador sin recibir un producto separado de software/hardware. No saltes de «SaaS» a «CRA se aplica». Comprueba definiciones y orientaciones actuales de la Comisión y evalúa por separado NIS2 cuando sea pertinente a la organización.

B. Producto de software con backend operado por fabricante

El cliente recibe una aplicación o componente cuya función importante no puede operar sin backend diseñado por el fabricante. El tratamiento remoto puede ser parte del producto a efectos CRA.

C. Producto que usa servicio de nube independiente

Si el servicio se diseña y desarrolla fuera de responsabilidad del fabricante, la relación puede diferir de un backend propio. «Los datos están en la nube» no responde por sí solo a la cuestión CRA.

Son ejemplos orientativos, no determinaciones jurídicas para una arquitectura concreta.

Por qué importa operativamente ahora

El artículo 14 se aplica desde el 11 de septiembre de 2026 y se extiende a productos incluidos puestos en el mercado antes del 11 de diciembre de 2027.

Si la oferta consiste en aplicación, componente y backend, el equipo necesita saber para producto y versión pertinentes:

  • dónde llegan comunicaciones de vulnerabilidades;
  • quién hace el triaje;
  • cómo se evalúa impacto en el producto;
  • cómo se publican correcciones;
  • cómo se informa a usuarios;
  • cuándo se activa evaluación de notificación CRA.

Sin límites claros del producto es difícil definir T0, responsabilidad o ámbito de notificación.

Qué registrar en una decisión de ámbito SaaS

  • diagrama de límites del producto;
  • elementos entregados localmente;
  • elementos ejecutados remotamente;
  • función de cada elemento;
  • si quitar el elemento remoto impide una función;
  • responsabilidad de desarrollar ese elemento;
  • modelo de distribución y marca;
  • papel de la organización;
  • fundamento jurídico/orientaciones de evaluación;
  • persona que aprueba;
  • próxima fecha de revisión.

Cómo ayuda Pulsar

Pulsar puede conservar decisión y artefactos de respaldo y conectar resultado con riesgos, documentos, acciones, proveedores y evidencias. Cuando cambia arquitectura en una versión posterior, la decisión vuelve a revisión en vez de seguir como PDF obsoleto.

Pulsar no debe dar autónomamente una respuesta jurídicamente definitiva «CRA se aplica / no se aplica» sin fundamento revisable ni aprobación humana.

Consulta Pulsar GRC en un flujo de evaluación

Orientaciones relacionadas

Método propuesto: una ficha de arquitectura por oferta comercial

Imagina una empresa que ofrece una consola web, una aplicación móvil y un agente instalado en los equipos del cliente. Todas se venden bajo la misma suscripción. Preguntar si «la suscripción» está incluida en CRA oculta diferencias importantes. La evaluación debe identificar los componentes suministrados, sus funciones y las soluciones remotas que puedan formar parte del producto conforme a las definiciones legales.

Prepara una ficha de arquitectura con una vista sencilla. El agente recoge información local, la aplicación muestra avisos y el backend procesa datos. Indica qué actor desarrolla cada componente, bajo qué responsabilidad y cómo llega al mercado. No hace falta exponer código ni secretos para explicar esos límites. Sí hace falta precisión suficiente para que otra persona comprenda qué depende de qué.

La ficha incluye una prueba conceptual: qué función dejaría de cumplirse si un componente remoto no estuviera disponible. Describe la función de forma concreta. «Mejora la experiencia» es demasiado ambiguo; «el agente no puede recibir la política necesaria para ejecutar su función prevista» permite analizar la dependencia. La conclusión jurídica requiere revisar los hechos y el texto aplicable, no solo ese ejemplo.

Separa oferta, producto y organización

Una empresa puede tener una oferta que contenga varios elementos con evaluaciones distintas. También puede desempeñar diferentes papeles respecto de componentes diferentes. Registra la unidad de análisis y conserva la relación con el contrato comercial. Esta separación evita extender una conclusión sobre una función web a un agente descargable que no fue evaluado.

La evaluación organizativa de NIS2 sigue otro recorrido. Puede depender de tipo de servicio, tamaño, excepciones y ley nacional. No uses un resultado CRA para concluir automáticamente que NIS2 no se aplica, ni al revés. Los dos expedientes pueden compartir documentos de arquitectura y continuidad, pero deben conservar fundamentos y aprobaciones propios. En una traducción, tampoco deben convertirse las reglas de un país en obligaciones idénticas para toda la Unión.

Si falta claridad sobre el papel de la empresa, consulta contratos, documentación de marca y modelo de distribución. El hecho de alojar un componente no define por sí solo quién asume la responsabilidad de desarrollarlo. Tampoco basta que el contrato use la palabra «servicio». Registra las dudas pendientes y quién debe resolverlas antes de cerrar la evaluación.

Tres decisiones de diseño que pueden cambiar el ámbito evaluado

La primera es añadir software que el cliente instala. Una función originalmente accesible por navegador puede incorporar después un agente, una extensión o una aplicación. Antes de lanzar el cambio, revisa si la evaluación anterior sigue cubriendo la nueva oferta. Conserva la versión del diagrama que se utilizó para decidir.

La segunda es trasladar una función esencial al backend propio. Eso puede cambiar la relación entre producto y tratamiento remoto. El equipo debe explicar qué ejecutaba antes el componente local y qué ejecuta ahora el servicio. Registra además los efectos sobre actualizaciones, vulnerabilidades y comunicación al usuario. Una modificación técnica pequeña en código puede ser material para el expediente.

La tercera es comercializar un componente desarrollado por otro proveedor bajo una marca distinta o introducir una modificación importante. Revisa el papel de operador económico conforme al caso concreto. No copies la conclusión del proveedor sin comprobar qué responsabilidad asume ahora tu organización. Conservar la fuente de la información recibida ayuda, pero no sustituye la evaluación propia.

Mantén una tabla de hechos y otra de conclusiones

Los hechos pueden incluir componentes entregados, versiones, funciones y responsables de desarrollo. Las conclusiones expresan cómo se interpretan esos hechos frente al reglamento y orientaciones. Tenerlas separadas permite actualizar una conclusión cuando cambia una fuente sin perder el inventario técnico. También permite detectar qué supuesto todavía necesita confirmación.

Para cada hecho relevante, indica una fuente: documentación de arquitectura, contrato, descripción de producto o revisión de ingeniería. Para cada conclusión, registra fundamento jurídico, persona que revisa y fecha. Si la IA propone una clasificación, trátala como borrador. La aprobación humana debe comprobar tanto los hechos como la inferencia, especialmente cuando una definición depende de cómo funciona realmente el producto.

Un expediente no gana calidad por afirmar más. Puede terminar con una cuestión abierta bien delimitada y una acción para resolverla. Es mejor que declarar «fuera de ámbito» porque el equipo no logró dibujar sus propios límites. La incertidumbre debe impedir afirmaciones comerciales definitivas que todavía no pueden defenderse.

Relaciona la decisión con la respuesta a vulnerabilidades

En el escenario propuesto, un aviso afecta al agente instalado, pero la corrección requiere modificar también el backend. El proceso debe identificar versiones locales utilizadas, servicio remoto relacionado y responsable de publicación. Si solo se registra el cambio del backend, puede perderse la relación con el producto afectado que sigue en manos de usuarios.

Ensaya una comunicación sobre ese cambio. Comprueba quién conoce los usuarios afectados, quién decide el tratamiento y cómo se documenta la disponibilidad de la corrección. No supongas que todos actualizan de inmediato. Registra ramas o configuraciones que necesitan seguimiento y conecta esa información con la evaluación de notificación cuando corresponda.

Criterios de aceptación de la evaluación SaaS

Una persona que no participó debe poder distinguir elementos locales, remotos y externos; explicar el papel de la empresa; localizar las fuentes y señalar cuándo se reabre la decisión. Si la respuesta depende únicamente de una etiqueta comercial, la evaluación no está terminada. Si el diagrama contradice el contrato o la documentación de ingeniería, registra y resuelve la diferencia.

Pulsar puede conservar este expediente y vincularlo a riesgos y acciones. La organización mantiene la revisión jurídica y técnica, y presenta por los canales correspondientes cualquier comunicación exigida. El resultado útil es un límite de producto explicado y revisable. Esa claridad permite organizar trabajo sin convertir el nombre «SaaS» en una exención ni en una obligación automática.

Revisa también una integración que el cliente pueda activar de forma opcional. Identifica qué función añade, quién desarrolla el componente y si cambia alguna dependencia necesaria para el producto evaluado. Una opción visible en la misma interfaz puede modificar los hechos utilizados en la decisión anterior. El expediente conserva las configuraciones cubiertas y señala las que todavía requieren revisión.

Como prueba, compara una configuración básica con otra que active esa función. Ingeniería explica diferencias; producto confirma cómo se ofrece; la persona competente revisa su efecto sobre el fundamento. No extiendas automáticamente una conclusión a todas las combinaciones ni conviertas la mera presencia de una integración en inclusión jurídica. Registra alcance, fuentes y aprobador.

Ensayar un requisito y un resultado revisado

Utilice un producto ficticio que consta de un cliente de escritorio y un backend operado por el fabricante. Este es un ejemplo de arquitectura sintética, no una declaración de que todos los servicios SaaS estén sujetos a la CRA. Primero registre la función del producto, la función del backend y la pregunta que necesita una revisión de alcance calificada. Mantenga la fuente legal y la decisión de revisión con el registro.

Una vez que los supuestos de aplicabilidad del ejemplo sean explícitos, elija un requisito relevante y una acción. Asigne un propietario y una fecha, luego defina qué evidencia demostraría el resultado de la acción. Por ejemplo, la acción puede revisar una regla de acceso a un producto y adjuntar la descripción y el resultado de la prueba ficticia. Una persona autorizada revisa la evidencia según el criterio establecido. Un archivo adjunto a la acción no completa esa revisión por sí solo.

En Pulsar, vuelva a leer el requisito, la acción vinculada, la versión fuente y la evidencia después de guardar. Pídale a un colega que identifique la próxima responsabilidad sin una explicación del autor. El resultado de la prueba concreta es un fragmento inspeccionable del trabajo del producto. No se trata de una clasificación automática de la CRA, una evaluación de la conformidad, una declaración CE ni una presentación ante una autoridad.

Pulsar ofrece una prueba de 14 días que requiere un método de pago. Revise el plan seleccionado, el precio posterior a la prueba y los términos de cancelación antes de confirmar. Utilice registros sintéticos para este ejercicio; una decisión real sobre el producto requiere su propia arquitectura y una revisión calificada.

Fuentes

Fuentes comprobadas: 12 de septiembre de 2026.

Vulnerabilidades de los componentes de IoT: proveedores, decisiones y soluciones

KSC/NIS2 polaco para proveedores de TI: evaluación y registro de acciones

API y MCP en GRC: defina el acceso antes de conectar sistemas