ENS para proveedores tecnológicos: cómo cumplir con la administración

Hay un momento que se repite en todas las empresas tecnológicas que trabajan —o quieren trabajar— con el sector público: aparece un pliego interesante, el equipo comercial lo lee con apetito, y en la página de prescripciones técnicas surge la frase: «el adjudicatario deberá acreditar la conformidad con el Esquema Nacional de Seguridad en la categoría correspondiente». Y ahí la pregunta ya no es si el ENS te afecta, sino cuánto te va a costar no haberlo preparado antes.

Quinto capítulo de nuestra serie sobre el Esquema Nacional de Seguridad, y el más directamente comercial de todos: cómo cumplir el ENS siendo proveedor tecnológico privado — desarrolladora, SaaS, consultora, hosting o integradora — para poder vender a la administración sin sustos. Si los capítulos anteriores explicaban el «qué» (los marcos organizativo, operacional y de protección), este explica el «para qué»: convertir el cumplimiento en contratos.

1. Por qué te afecta aunque seas una empresa privada

El error de partida más común: pensar que el ENS es «cosa de la administración». Lo era en espíritu en 2010; dejó de serlo negro sobre blanco con el RD 311/2022, cuyo ámbito de aplicación incluye expresamente los sistemas de las entidades privadas que presten servicios o provean soluciones a las entidades públicas. Traducido: si tu plataforma trata información pública, si operas un servicio que usa un ayuntamiento, o si desarrollas y mantienes la sede electrónica de un organismo, tu sistema entra en el alcance del esquema — no solo el de tu cliente.

La lógica es la de toda cadena de suministro: la administración no puede proteger su información si el eslabón privado que la trata queda fuera del esquema. Es el mismo movimiento que hemos visto en el sector privado con las auditorías a proveedores de la ISO 27001, pero con rango de real decreto y con un mecanismo de verificación mucho más concreto: la conformidad acreditable. Al contratista se le puede —y cada vez más, se le suele— exigir que la demuestre.

El matiz importante: el ENS no aplica a «tu empresa» en abstracto, sino al sistema de información que da soporte al servicio público. Eso delimita el alcance (y el coste): no necesitas meter en el esquema tu CRM comercial ni tus proyectos de clientes privados — necesitas identificar qué sistemas tocan el servicio prestado a la administración y adecuar esos.

2. Qué exige la administración en las licitaciones

La exigencia llega por el pliego. En los últimos años, la referencia al ENS ha pasado de cláusula exótica a requisito estándar en la contratación tecnológica pública, con tres formatos habituales:

• Requisito de solvencia o condición de ejecución: el pliego exige la conformidad con el ENS en una categoría concreta (básica, media o alta), acreditada mediante certificación o declaración según corresponda. Sin ella, tu oferta no pasa el corte administrativo — da igual lo buena que sea técnicamente.
• Compromiso de adecuación: algunos pliegos aceptan un compromiso de obtener la conformidad en un plazo desde la adjudicación. Es la vía de entrada para quien llega tarde, pero ojo: firmar un compromiso a 6 meses sin haber empezado la adecuación es firmar un proyecto a contrarreloj con penalizaciones detrás.
• Requisitos técnicos trasladados: aunque no pidan el sello, los pliegos incorporan medidas concretas del Anexo II (cifrado, trazabilidad, continuidad, desarrollo seguro) como prescripciones técnicas que tendrás que cumplir y evidenciar durante la ejecución.

Y una tendencia que conviene tener en el radar: los servicios cloud que usan las administraciones deben estar ellos mismos conformes con el ENS. Si tu SaaS corre sobre un hyperscaler, la buena noticia es que las regiones europeas de los grandes proveedores ya cuentan con certificaciones ENS que puedes heredar en tu Declaración de Aplicabilidad — como vimos al hablar de la herencia en las medidas de protección. La mala: la herencia cubre la infraestructura, no tu aplicación. El sello del cloud no te certifica a ti.

3. Determinar la categoría que te exigirán (y la que te conviene)

La categoría de tu sistema no la eliges tú por ambición ni por marketing: se deriva de la valoración de la información y los servicios que tratas, en las cinco dimensiones que repasamos en la guía central (confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad). Pero como proveedor hay una regla práctica que simplifica el análisis: tu sistema debe estar a la altura de la categoría del servicio público al que das soporte, y esa categoría la fija el cliente — el responsable de la información es él.

En la práctica del mercado español:

• Categoría BÁSICA: webs informativas, portales sin tramitación, servicios auxiliares sin datos sensibles. Suficiente para buena parte del trabajo de desarrollo municipal pequeño.
• Categoría MEDIA: el estándar de facto de la contratación tecnológica: sedes electrónicas, plataformas de tramitación, sistemas con datos personales significativos, la mayoría de SaaS para administraciones. Si vendes producto o servicio recurrente al sector público, este es tu objetivo razonable.
• Categoría ALTA: sistemas críticos, sanidad con historia clínica, seguridad ciudadana, servicios esenciales. Requisitos reforzados en casi todas las medidas — solo tiene sentido si tu nicho lo exige.

El consejo estratégico: certifica la categoría que tu pipeline comercial necesita, no la máxima posible. Pasar de media a alta multiplica requisitos (y coste de mantenimiento) y solo compensa si hay contratos concretos al otro lado. Subir de categoría más adelante es un incremento sobre lo ya construido, no empezar de cero.

4. La Certificación de Conformidad: el sello que abre el pliego

La conformidad con el ENS se acredita de dos maneras, y la diferencia importa mucho a la hora de presupuestar:

• Declaración de Conformidad — solo válida para categoría básica: una autoevaluación formal, publicando el distintivo correspondiente. Sin auditor externo obligatorio.
• Certificación de Conformidad — obligatoria para categorías media y alta (y disponible también para básica, donde aporta más credibilidad que la autoevaluación): una auditoría formal realizada por una entidad de certificación acreditada por ENAC, que emite el certificado y te habilita a usar el distintivo de conformidad.

El proceso, si vienes de la serie, te resultará familiar: preparación de la documentación (política, valoración y categorización, análisis de riesgos, Declaración de Aplicabilidad, plan de adecuación si hay gaps), implantación de las medidas del Anexo II que apliquen a tu categoría, auditoría con revisión documental y verificación técnica, informe, corrección de no conformidades y emisión del certificado. La certificación tiene ciclo bienal, con la vigilancia correspondiente — y el distintivo, que es lo que el órgano de contratación quiere ver, enlaza con tu certificado vigente.

¿Plazos y esfuerzo realistas para una pyme tecnológica con base técnica sana que apunta a categoría media? Entre 4 y 8 meses desde el arranque hasta el certificado, con el grueso del esfuerzo en documentar lo que ya haces y cerrar los gaps clásicos (trazabilidad centralizada, continuidad probada con acta, formalizar el SDLC). Si has seguido esta serie, ya sabes que el 80% del Anexo II es ingeniería razonable que una plataforma bien construida debería tener de todos modos.

5. Las guías CCN-STIC: el manual de instrucciones oficial

El Centro Criptológico Nacional (CCN) publica la serie de guías CCN-STIC 800, que son el desarrollo práctico del esquema. Para un proveedor, las imprescindibles:

• CCN-STIC 801 — responsabilidades y funciones: quién es responsable de la información, del servicio y de la seguridad. Clave para el reparto contractual con tu cliente público.
• CCN-STIC 803 — valoración de sistemas: cómo se determina la categoría. La que usarás para validar (o discutir con criterio) el nivel que te piden.
• CCN-STIC 804 — guía de implantación: las medidas del Anexo II desarrolladas una a una. Tu manual de cabecera durante la adecuación.
• CCN-STIC 806 — plan de adecuación: la estructura del documento que ordena tus gaps y plazos.
• CCN-STIC 809 — declaración y certificación de conformidad y sus distintivos: el reglamento del sello que quieres conseguir.

Mención aparte para los perfiles de cumplimiento específicos que el CCN aprueba para colectivos concretos (entidades locales pequeñas, universidades, determinados servicios cloud): adaptan el catálogo de medidas a la realidad de cada contexto y pueden simplificar sensiblemente una adecuación. Antes de atacar el Anexo II completo, comprueba si tu caso encaja en alguno — y de paso, el portal del CCN (con su ecosistema de herramientas y formación) es de lo más aprovechable del cumplimiento español: gratuito, técnico y actualizado.

6. El impacto real en startups y pymes tecnológicas

Seamos francos con los números, como hicimos con la ISO 27001 para pymes: para una empresa de 10-30 personas, una adecuación ENS a categoría media con acompañamiento externo se mueve típicamente en la horquilla de 10.000-25.000 € el primer año (consultoría + auditoría de certificación + herramientas), más el coste interno en horas — que es el de verdad relevante y depende brutalmente de tu punto de partida. Una plataforma con CI/CD disciplinado, cloud bien segmentado y logging centralizado está a semanas del papel; una arquitectura heredada sin trazabilidad está a un proyecto de ingeniería del sello.

¿Compensa? Depende de una única variable: si el sector público está en tu estrategia comercial. Si lo está, el cálculo suele ser rotundo — un solo contrato medio de la administración paga la adecuación varias veces, y el sello funciona además como barrera de entrada frente a competidores que no lo tienen. Para una startup que construye producto, además, hay un momento óptimo: incorporar los requisitos del ENS cuando la arquitectura aún es joven cuesta una fracción que retrofitearlos con el producto en producción — la misma lección de deuda técnica que contamos al hablar de los errores técnicos que hunden MVPs: lo que no diseñas pronto, lo pagas caro tarde.

Y el efecto colateral que casi nadie anticipa: la adecuación ENS te deja a un paso de la ISO 27001 (y viceversa). Los solapamientos del Anexo II con el Anexo A son enormes — los hemos ido señalando capítulo a capítulo — y una estrategia dual bien planteada consigue los dos sellos generando cada evidencia una sola vez. Del cara a cara detallado entre ambos marcos nos ocupamos en el próximo capítulo de la serie.

7. Estrategia de cumplimiento eficiente: el plan del proveedor

Nuestra receta para llegar al sello sin convertir la empresa en una fábrica de papel, destilada de lo que funciona en proyectos reales:

• 1. Delimita el alcance con bisturí. Solo los sistemas que soportan el servicio al sector público. Un alcance quirúrgico reduce el coste de todo lo demás: menos activos, menos riesgos, menos medidas, menos auditoría.
• 2. Decide la categoría con el pipeline delante. Media es el punto dulce para la mayoría de proveedores. Valídala contra los pliegos que realmente quieres ganar.
• 3. Hereda todo lo heredable. Cloud certificado, datacenter, servicios gestionados conformes: cada herencia documentada es una familia de medidas que no implementas tú. La Declaración de Aplicabilidad es donde se cristaliza.
• 4. Construye sobre tu flujo real. Como venimos repitiendo en toda la serie: el SDLC sobre tus PRs reales, la trazabilidad sobre tu logging real, la continuidad sobre tus backups reales. El auditor certifica lo que existe, no lo que luce.
• 5. Ordena por retorno. Primero lo que reduce riesgo real y genera evidencia automática (canal cifrado, MFA, backups probados, logging centralizado); después el papel que lo describe; al final el distintivo que lo cuenta.
• 6. Si también quieres la ISO, hazlas juntas. Un solo análisis de riesgos, un solo cuerpo documental con doble mapeo, dos auditorías coordinadas. La vía dual cuesta bastante menos que las dos por separado.

8. El reparto de responsabilidades con tu cliente público

Un frente que conviene cerrar por escrito antes de que lo cierre un incidente: en la relación proveedor-administración, el ENS distingue entre el responsable de la información y del servicio (normalmente tu cliente: él decide qué se protege y cuánto), y el responsable de la seguridad y del sistema del lado de quien opera — que en un servicio externalizado eres, en gran parte, tú. La guía CCN-STIC 801 detalla este mapa de figuras, y el contrato debe traducirlo: quién valora y califica la información, quién autoriza cambios y puestas en producción, quién notifica incidentes a quién y en qué plazos, y cómo se coordinan vuestros respectivos POC de seguridad.

Tres cláusulas que recomendamos dejar siempre explícitas en el acuerdo o en el plan de seguridad del servicio:

• Gestión de incidentes compartida: tu obligación de notificación al cliente (y la suya hacia su CSIRT de referencia) con plazos concretos, para que un incidente en tu plataforma no se convierta además en un incumplimiento contractual por silencio.
• Derecho de auditoría acotado: la administración puede querer verificar tus medidas; pactar el formato (evidencias documentales, tu certificado vigente, auditoría con preaviso) evita que cada contrato invente el suyo.
• Reversibilidad y fin de servicio: qué pasa con la información pública al terminar el contrato — devolución, borrado certificado y plazos. Es exactamente la disciplina de fin de vida de los datos que vimos en las medidas de protección, elevada a cláusula.

9. Mini-FAQ del proveedor ante el ENS

Un pliego pide «certificación ENS categoría media» y no la tenemos: ¿estamos fuera?

Depende de cómo esté redactado el requisito: si es condición de solvencia, sí; si admite compromiso de adecuación o se exige para la ejecución, puedes concurrir arrancando la adecuación ya — con plazos honestos, porque el compromiso incumplido se convierte en penalización. La lectura fina del pliego (y consultar al órgano de contratación en fase de preguntas) vale más que cualquier suposición.

Nuestro cloud ya está certificado ENS: ¿no basta con eso?

No. La certificación del proveedor cloud cubre sus capas (la infraestructura que le compras) y te permite heredar esas medidas, pero tu aplicación, tu operación y tu organización siguen siendo responsabilidad tuya y necesitan su propia conformidad. El sello de AWS, Azure o Google no aparece con tu nombre en el distintivo.

¿La Declaración de Conformidad (autoevaluación) me sirve para vender?

Solo si el sistema es de categoría básica y el pliego la acepta. Para media y alta la certificación por entidad acreditada es obligatoria — y en la práctica comercial, incluso en básica, el certificado convence más que la autodeclaración. Si el sector público es estratégico, apunta al certificado.

¿Cada contrato con la administración exige repetir el proceso?

No: la conformidad es de tu sistema, no de cada contrato. Una vez certificado, el mismo distintivo sirve para todas las licitaciones cuyo requisito encaje con tu categoría y alcance. Lo que sí revisarás por contrato es que el servicio concreto quede dentro del alcance certificado — y ampliarlo si no.

Conclusión: el ENS como inversión comercial, no como peaje

Para un proveedor tecnológico, el ENS tiene una particularidad que ningún otro marco de esta serie comparte: es el único cuyo retorno se mide en contratos concretos. La ISO 27001 te posiciona; el ENS te habilita — sin él, hay una parte creciente del mercado público español que simplemente no puedes tocar. Visto así, la pregunta cambia: no es «cuánto cuesta cumplir», sino «cuánto cuesta cada pliego que dejas pasar».

Si has llegado hasta aquí desde el principio de la serie, ya tienes el mapa completo: el esquema y sus reglas, los tres bloques de medidas capítulo a capítulo, y ahora el camino comercial del sello. Queda el último movimiento: poner el ENS y la ISO 27001 frente a frente para decidir cuál priorizar — o cómo conseguir los dos pagando (casi) uno. Nos vemos en el próximo capítulo.