ENS para vender software y SaaS al sector público: lo que te van a exigir

Si quieres vender software o un servicio SaaS a la Administración española, necesitas el Esquema Nacional de Seguridad. No es una recomendación: el artículo 2.3 del Real Decreto 311/2022 extiende el ENS a los sistemas de información de las empresas privadas que, en virtud de una relación contractual, prestan servicios o proveen soluciones al sector público para el ejercicio de sus competencias. Y el mismo artículo obliga a que los pliegos de los contratos públicos incluyan los requisitos de conformidad con el ENS, «tales como la presentación de las correspondientes Declaraciones o Certificaciones de Conformidad». Traducido al día a día comercial: el pliego te pedirá una declaración de conformidad (si el sistema es de categoría BÁSICA) o una certificación emitida por una entidad acreditada (si es MEDIA o ALTA), y sin ese papel tu oferta no compite.

Esta guía está escrita para el que vende: fabricantes de software, plataformas SaaS y proveedores cloud que quieren entrar en licitaciones públicas o que ya han perdido alguna por no tener el ENS. Si lo que buscas es el marco general de la norma, está en la guía completa del Esquema Nacional de Seguridad; si tu duda es si tu empresa está obligada o no, empieza por quién debe cumplir el ENS; y el resto de guías del vertical están en el área de ENS.

Por qué el ENS te aplica aunque tu empresa sea privada

El ENS nació para el sector público, pero desde el Real Decreto 311/2022, de 3 de mayo, alcanza de lleno a sus proveedores tecnológicos. La lógica es sencilla: si un ayuntamiento tramita expedientes con tu plataforma, la seguridad de ese servicio público depende de tus sistemas, no de los suyos. Por eso el artículo 2.3 mete dentro del ámbito de aplicación «los sistemas de información de las entidades del sector privado» cuando prestan servicios o proveen soluciones a entidades públicas para el ejercicio de sus competencias y potestades administrativas.

Para un proveedor SaaS esto tiene tres consecuencias concretas:

1. Tu sistema entra en el ámbito del ENS, con la obligación expresa de contar con una política de seguridad conforme al artículo 12 del real decreto. En una empresa privada, esa política la aprueba «el órgano que ostente las máximas competencias ejecutivas»: el consejo de administración o el administrador, no el responsable de sistemas.
2. El pliego debe exigirte la conformidad. No depende de la buena voluntad del órgano de contratación: el propio artículo 2.3 ordena que los pliegos de prescripciones administrativas o técnicas contemplen los requisitos necesarios para asegurar la conformidad con el ENS de los sistemas que sustentan el servicio contratado.
3. La exigencia se extiende a tu cadena de suministro «en la medida que sea necesario y de acuerdo con los resultados del correspondiente análisis de riesgos». Si tu SaaS corre sobre un proveedor de infraestructura cloud, la conformidad de ese proveedor forma parte de tu ecuación.

Conviene decirlo claro: ya no hay periodo de gracia. La disposición transitoria única dio veinticuatro meses a los sistemas preexistentes, incluidos los de los contratistas privados, para adecuarse; el real decreto entró en vigor al día siguiente de su publicación en el BOE (4 de mayo de 2022), así que ese plazo terminó en mayo de 2024. Los sistemas nuevos, además, deben aplicar el ENS «desde su concepción». Quien licita hoy sin conformidad no va tarde respecto a una fecha futura: va tarde respecto a una que ya pasó.

Qué dice exactamente el Real Decreto 311/2022

Del texto consolidado del real decreto, estos son los artículos que un proveedor de software debe conocer casi de memoria:

Dos detalles del artículo 28 que se pasan por alto: las medidas del anexo II son «mínimos exigibles» ampliables por el responsable de la seguridad, y pueden sustituirse por medidas compensatorias cuando esté justificado. La selección final se formaliza en la Declaración de Aplicabilidad, firmada por el responsable de la seguridad. Para un SaaS con arquitectura propia, esa flexibilidad importa: no se trata de calcar una lista, sino de defender con un análisis de riesgos qué medidas protegen de verdad tu plataforma.

Básica, media o alta: qué categoría te van a pedir

La categoría no la eliges tú por comodidad ni te la asigna la norma por tamaño de empresa. Se determina valorando el impacto que tendría un incidente sobre cinco dimensiones de la seguridad (anexo I): confidencialidad, integridad, trazabilidad, autenticidad y disponibilidad. Cada dimensión afectada se adscribe a un nivel BAJO, MEDIO o ALTO según el perjuicio —limitado, grave o muy grave— que causaría el incidente, y del conjunto sale la categoría del sistema.

Además, el artículo 41 reparte los papeles: la valoración de la información y de los servicios corresponde a sus responsables (en un contrato público, la entidad contratante es responsable de su información y de su servicio), y con esas valoraciones el responsable de la seguridad determina la categoría del sistema. En la práctica comercial esto significa que la categoría que necesitas viene marcada por los servicios públicos que tu software sustenta, y lo habitual es encontrarla escrita en el pliego.

Como orientación, sin sustituir la valoración formal de cada caso: un sistema que trata datos personales de ciudadanos en volumen apreciable o que sustenta un servicio cuya caída causaría un perjuicio grave rara vez se queda en BÁSICA. Por eso la mayoría de proveedores SaaS que venden a la Administración acaban necesitando categoría MEDIA, y conviene asumirlo desde el principio en lugar de certificar BÁSICA y descubrir en el siguiente pliego que no basta. El criterio completo para decidirlo está en cómo elegir entre categoría básica, media y alta.

Declaración o certificación: la diferencia que decide contratos

El artículo 38 establece dos vías de conformidad:

• Categoría BÁSICA: basta una autoevaluación que desemboca en una Declaración de Conformidad. Puedes, si quieres, someterte igualmente a una auditoría de certificación, y a efectos comerciales suele compensar: un certificado pesa más que una autodeclaración.
• Categorías MEDIA y ALTA: se exige una auditoría de certificación. La auditoría de seguridad bienal del artículo 31 puede servir a la vez para la certificación.

La certificación no la emite cualquiera: solo pueden certificar la conformidad con el ENS las entidades de certificación acreditadas por ENAC para ese esquema. Desconfía de quien te ofrezca «certificados ENS» sin esa acreditación; ante un órgano de contratación no valen nada.

Dos obligaciones asociadas que conviene apuntar en el calendario: la conformidad se hace pública mediante los distintivos de conformidad (el artículo 38.2 obliga a dar publicidad a declaraciones y certificaciones en el portal de internet), y la auditoría ordinaria se repite al menos cada dos años, además de con carácter extraordinario si hay modificaciones sustanciales del sistema. Un certificado ENS no es un trámite que se hace una vez: es un ciclo.

El camino práctico para un SaaS: de cero a certificado

El orden importa. Este es el recorrido que funciona para una empresa de producto:

1. Define el alcance. El ENS se certifica sobre sistemas de información, no sobre empresas enteras. Para un SaaS, el alcance natural es la plataforma que presta el servicio a clientes públicos: aplicación, infraestructura que la sustenta, procesos de operación y el personal que la administra. Un alcance mal definido es el error más caro de todo el proceso.
2. Mide tu punto de partida. Antes de contratar nada, pásale a tu sistema el autodiagnóstico ENS: te sitúa frente a las medidas del anexo II y te da una foto honesta de la distancia que te queda.
3. Haz el análisis de riesgos. Es la piedra angular del ENS (artículo 14 del real decreto exige gestionar la seguridad basándose en los riesgos). El CCN ofrece PILAR como herramienta oficial.
4. Selecciona medidas y redacta la Declaración de Aplicabilidad. Con la categoría fijada, el anexo II te dice qué medidas aplican; el análisis de riesgos justifica refuerzos y compensatorias.
5. Implanta y documenta. Política de seguridad aprobada por el máximo órgano ejecutivo, normativa interna, procedimientos operativos, registro de actividad, gestión de incidentes. En un SaaS, buena parte de las medidas ya existen a medias (control de accesos, copias, cifrado); el grueso del trabajo suele ser sistematizarlas y dejar evidencias.
6. Audita y certifica. Auditoría interna previa si el margen lo permite, y auditoría de certificación con entidad acreditada por ENAC. Con el certificado, solicita el distintivo y publícalo.

Si tu plataforma corre sobre un hiperescalador o un proveedor cloud español, revisa su propia conformidad con el ENS y su alcance: te ahorra implantar (y defender ante el auditor) las medidas que ya cubre la capa de infraestructura, y responde a la exigencia de cadena de suministro del artículo 2.3. El supuesto general de aplicación al sector privado está desarrollado en cuándo aplica el ENS al sector privado.

Perfiles de cumplimiento específicos: el atajo pensado para ti

El artículo 30 del real decreto es el gran desconocido entre los proveedores de producto, y es precisamente el que piensa en ellos. Permite dos cosas:

• Perfiles de cumplimiento específicos: conjuntos de medidas ajustados a entidades o sectores concretos, validados y publicados por el Centro Criptológico Nacional, que aplican el principio de proporcionalidad para que el esfuerzo case con el riesgo real.
• Esquemas de acreditación para soluciones y plataformas de terceros (artículo 30.2): mecanismos para garantizar que las soluciones suministradas por proveedores privados que van a usar las entidades públicas son conformes con el ENS.

El apartado 4 añade algo muy relevante para el mundo SaaS: las instrucciones técnicas de seguridad y las guías CCN-STIC precisarán las condiciones de las implementaciones en modo local de productos, sistemas o servicios originariamente prestados en la nube, y sus condiciones de evaluación y auditoría. Si ofreces despliegues on-premise de tu producto cloud a clientes públicos, ese régimen te concierne. Antes de arrancar tu proyecto de adecuación, comprueba en el portal del ENS del CCN si existe un perfil de cumplimiento aplicable a tu caso: puede reducir el conjunto de medidas a implantar.

Cuánto cuesta y cuánto se tarda

Horquillas orientativas a julio de 2026, para que hagas números antes de decidir; el coste real depende del alcance, del punto de partida y de la categoría. No hay tarifa oficial del ENS: ni el CCN ni ENAC publican precios, así que todo esto es precio de mercado.

• Implantación con consultoría para una pyme con categoría MEDIA: entre 12.000 y 35.000 euros.
• Auditoría de certificación con entidad acreditada: entre 4.000 y 15.000 euros adicionales en categoría MEDIA, y entre 8.000 y 25.000 en ALTA.
• Proyecto completo del primer año, sumando adecuación y auditoría: entre 10.000 y 50.000 euros, con la mayoría de las pymes cerrando entre 15.000 y 30.000.
• Mantenimiento del ciclo: la auditoría se repite al menos cada dos años, y hay que presupuestar la dedicación interna continua (responsable de seguridad, gestión de incidentes, revisión documental).

El desglose por partidas —análisis de riesgos, documentación, adecuación técnica, auditoría y mantenimiento— y qué dispara cada una está en la guía de certificación ENS: proceso, requisitos y costes.

En plazos, un proyecto de adecuación y certificación de categoría MEDIA para un SaaS con prácticas de seguridad razonables suele moverse entre cuatro y nueve meses. Con una madurez baja de partida, más. La consecuencia comercial es directa: si esperas a ver el ENS escrito en un pliego para empezar, ese contrato ya no es tuyo. Los plazos de presentación de ofertas se miden en semanas y ninguna certificación seria cabe ahí.

Qué mirar en el pliego antes de ofertar

Cuando llegue el pliego, busca estas cuatro cosas antes de decidir si ofertas:

• La categoría exigida. Debe estar determinada; si el pliego exige «conformidad con el ENS» sin categoría, pide aclaración en fase de consultas.
• Cómo se exige la conformidad: como requisito de solvencia técnica, como criterio de adjudicación o como condición especial de ejecución. Cambia el momento en el que tienes que acreditarla y el riesgo de quedar excluido.
• Qué documento aceptan: certificación de entidad acreditada, declaración de conformidad, o compromiso de adecuación con plazo. Cada órgano de contratación lo redacta a su manera.
• Las cláusulas de cadena de suministro: si el pliego traslada requisitos ENS a tus subcontratistas y proveedores cloud, necesitarás sus evidencias de conformidad para responder.

Y una comprobación previa que no está en el pliego sino en tu producto: verifica que el alcance de tu certificado cubre el servicio concreto que vas a ofertar. Un certificado ENS de un sistema distinto al que sustentará el contrato no acredita nada.

Errores frecuentes de los proveedores SaaS

• Confundir ISO 27001 con ENS. Se complementan y comparten terreno, pero no son intercambiables: la ISO 27001 es una norma internacional de sistemas de gestión (de pago, no pública) y el ENS es una obligación legal española con medidas concretas por categoría. Tener la ISO acelera la adecuación porque ya existe gobierno de la seguridad, pero no sustituye la declaración ni la certificación ENS que pide el pliego.
• Certificar el alcance equivocado. Certificar las oficinas y el correo corporativo en lugar de la plataforma que presta el servicio público. El órgano de contratación (y su auditor) mirarán el alcance, no el logotipo.
• Quedarse en BÁSICA por ahorrar. Si tus clientes objetivo tramitan datos de ciudadanos, lo probable es que el pliego pida MEDIA. Recertificar en categoría superior cuesta más que empezar bien.
• Olvidar el ciclo de vida. Auditoría al menos bienal, auditoría extraordinaria si cambias sustancialmente el sistema, re-evaluación de la categoría cuando cambian información o servicios. Un certificado caducado en mitad de un contrato es un incumplimiento contractual.
• Ignorar a tus proveedores. Tu conformidad se apoya en la de tu infraestructura. Si tu cloud no puede acreditar nada, ese hueco aparecerá en tu auditoría.

Preguntas frecuentes

Fuentes

• Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad — texto consolidado (BOE-A-2022-7191)
• Portal del Esquema Nacional de Seguridad — Centro Criptológico Nacional
• ENAC — Entidad Nacional de Acreditación
• Instrucción Técnica de Seguridad de conformidad con el Esquema Nacional de Seguridad (Resolución de 13 de octubre de 2016, BOE-A-2016-10109), apartado VI: acreditación de las entidades certificadoras por ENAC conforme a UNE-EN ISO/IEC 17065:2012.