Cuándo se aplica el ENS a una empresa de software
El Esquema Nacional de Seguridad, regulado por el Real Decreto 311/2022, se diseñó para las administraciones públicas. Llega a las empresas privadas a través del artículo 2, que lo extiende a los sistemas de información con los que los proveedores privados prestan servicios o proveen soluciones a las entidades del sector público. El mismo artículo obliga a esas entidades a exigir la conformidad con el ENS en sus contratos. Una empresa de software se encuentra con el ENS por primera vez en un pliego o en una cláusula de renovación, no en una carta del regulador.
Para una empresa SaaS el detonante es concreto: un ayuntamiento, un servicio de salud autonómico, una universidad o un ministerio quiere usar el producto, y el producto va a tratar su información o dar soporte a uno de sus servicios. A partir de ese momento, el sistema que presta el servicio tiene que ser conforme con el ENS en la categoría que exija la entidad contratante. Nuestro artículo sobre qué hacer cuando el pliego exige el ENS cubre las primeras semanas tras ese requisito.
El ENS se aplica al sistema, no a la empresa entera. Un proveedor SaaS con varios productos puede limitar el ENS al que vende al sector público, siempre que los límites estén claros y los componentes compartidos, como el proveedor de identidad, la cadena de despliegue o el equipo de soporte, queden dentro.
Cómo se fija la categoría del sistema
El Anexo I del RD 311/2022 determina la categoría de un sistema a partir del impacto que tendría un incidente de seguridad en cinco dimensiones: confidencialidad, integridad, trazabilidad, autenticidad y disponibilidad. Cada dimensión se valora como baja, media o alta, y la categoría es la valoración más alta de las cinco. Un sistema con una sola dimensión alta es de categoría ALTA, aunque las otras cuatro sean bajas.
En la práctica, la entidad pública categoriza el servicio que contrata y traslada el resultado al pliego. El trabajo del proveedor es entender por qué se eligió esa categoría y definir el alcance en consecuencia. Un producto SaaS que guarda datos personales de la ciudadanía, da soporte a un procedimiento con plazos legales o trata información sanitaria rara vez será de categoría BÁSICA. Nuestro artículo sobre si el ENS se aplica a tu empresa y en qué nivel explica la categorización en detalle.
Autoevaluación o certificación
La categoría determina cómo se acredita la conformidad. Un sistema de categoría BÁSICA puede obtener una declaración de conformidad basada en una autoevaluación, aunque muchos proveedores optan igualmente por una auditoría de certificación porque el comprador confía más en ella. Los sistemas de categoría MEDIA y ALTA necesitan una certificación de conformidad emitida tras una auditoría por una entidad de certificación acreditada por ENAC para el esquema ENS.
El artículo 31 del RD 311/2022 exige una auditoría ordinaria al menos cada dos años, y una auditoría extraordinaria cuando se producen modificaciones sustanciales en el sistema. Para una empresa SaaS que despliega cambios de forma continua, conviene decidir qué se considera sustancial antes de la primera auditoría, no después. La auditoría se describe en nuestro artículo sobre cómo funciona la auditoría del ENS.
Qué entra en el alcance de un producto SaaS
El alcance de un sistema ENS para un producto SaaS suele tener cuatro capas. La primera es el entorno de producción que ejecuta el servicio, con las cuentas cloud, las redes y las bases de datos. La segunda es el código y la cadena que lo despliega, porque los cambios en producción se hacen ahí. La tercera son las personas que operan y dan soporte al servicio, con sus equipos y sus accesos. La cuarta son los proveedores externos de los que depende el servicio, desde la plataforma cloud hasta el servicio de correo que envía las notificaciones.
Dejar la cadena de despliegue o el equipo de soporte fuera del alcance es un error habitual. El auditor sigue el camino que recorre un cambio hasta producción y el que recorre un técnico de soporte hasta los datos del cliente. Si alguno de esos caminos atraviesa una zona fuera del alcance, las medidas que protegen el sistema están incompletas.
Qué añade la nube: la medida op.nub.1
El RD 311/2022 introdujo una medida específica para los servicios en la nube, op.nub.1, dentro del marco operacional del Anexo II. Se aplica cuando el sistema utiliza servicios en la nube prestados por un tercero, que es la situación normal de una empresa SaaS construida sobre un gran proveedor de infraestructura. La medida exige que el servicio cumpla el nivel de seguridad del sistema y, en las categorías superiores, que cuente con su propia certificación ENS y se configure siguiendo las guías del Centro Criptológico Nacional.
Los grandes proveedores de infraestructura tienen certificaciones ENS para muchos de sus servicios, pero cada certificación cubre servicios y regiones concretos. La empresa SaaS tiene que comprobar que los servicios que realmente usa están dentro del certificado de su proveedor y que su propia configuración sigue las guías CCN-STIC aplicables. Una plataforma cloud certificada con una configuración sin bastionar no cumple op.nub.1.
El ENS no contiene una regla general que obligue a mantener los datos en España. Sí exige que el proveedor conozca y controle dónde se tratan, bajo qué jurisdicción y con qué cifrado y gestión de claves. Algunos pliegos añaden requisitos explícitos de localización, que pasan a ser obligaciones contractuales.
Las medidas que suelen generar trabajo
El catálogo completo se explica en nuestro artículo sobre las medidas de seguridad del Anexo II del ENS. En una empresa SaaS, las medidas que más trabajo nuevo suelen exigir son estas:
- La diferenciación de responsabilidades del artículo 11, que separa al responsable de la información, del servicio, de la seguridad y del sistema. En una empresa pequeña requiere un diseño cuidadoso.
- El control de acceso, op.acc, con autenticación robusta y revisión de los accesos privilegiados a producción.
- El registro de la actividad, op.exp.8, con registros que se conservan, se protegen y se revisan de verdad.
- La gestión de servicios externos, op.ext, con requisitos de seguridad documentados para cada proveedor.
- El desarrollo y la aceptación de aplicaciones, mp.sw.1 y mp.sw.2, que cubren el desarrollo seguro y las pruebas antes de cada versión.
- Las copias de seguridad, mp.info.6, con restauraciones probadas y no solo una captura de la configuración.
Partir de ISO 27001
Muchas empresas SaaS ya tienen ISO 27001 cuando llega el primer requisito ENS. Los dos marcos comparten la lógica de un sistema de gestión basado en riesgos, y buena parte de las evidencias se puede reutilizar. Pero el ENS no es un subconjunto de ISO 27001. Sus medidas son prescriptivas, crecen con la categoría y añaden los roles del artículo 11 y las guías del CCN. Nuestro artículo sobre gestionar ISO 27001 y ENS como un programa único explica cómo evitar mantener dos juegos de documentos en paralelo.
Dónde encaja Qalea
Un certificado ENS para un producto SaaS depende de medidas que funcionan cada día: accesos vigilados, registros revisados, copias probadas y cambios controlados. Qalea opera los controles que hay detrás de esas medidas, con una plataforma de cumplimiento mapeada al Anexo II y una capa de monitorización con EDR, SIEM y un SOC que genera las evidencias operativas que revisa el auditor. Así, una empresa sin equipo de seguridad propio cubre las medidas del Anexo II con evidencias que se generan de forma continua. Dejamos el sistema preparado para la auditoría y lo mantenemos así entre auditorías, como explicamos en nuestro artículo sobre mantener la certificación ENS. Más sobre el esquema en nuestro espacio dedicado al ENS.
