ENS para empresas tecnologicas: guia practica de certificacion

Por que el ENS importa ahora

El Esquema Nacional de Seguridad ya no es solo para la administracion publica. Desde la actualizacion del Real Decreto 311/2022, cualquier empresa tecnologica que preste servicios al sector publico espanol — o que aspire a hacerlo — necesita certificarse. Y el mercado lo ha notado: los pliegos de contratacion publica incluyen cada vez mas el ENS como requisito, no como merito.

Para una empresa tecnologica de 30-200 personas, la certificacion ENS puede parecer un ejercicio burocratico. No lo es, o no deberia serlo. Bien ejecutado, el proceso ordena la seguridad de la organizacion y genera un marco reutilizable para otras certificaciones (ISO 27001, SOC 2). Mal ejecutado, es un proyecto de documentacion que se desactualiza el dia despues de la auditoria.

Esta guia asume que tu empresa es un proveedor tecnologico (desarrollo de software, cloud, datos, consultoria) que necesita certificacion ENS en categoria media. Es el escenario mas comun y el que mas matices tiene.

Fase 1: Gap analysis (semanas 1-3)

El gap analysis es la fase que mas equipos quieren saltar y la que mas valor aporta. Sin saber donde estas, no puedes planificar donde necesitas llegar.

Que evaluar

El ENS en categoria media exige 55 medidas de seguridad agrupadas en tres marcos:

Marco organizativo (org): Politica de seguridad, normativa de seguridad, procedimientos operativos, proceso de autorizacion. Son documentos, pero no documentos vacios. El auditor verificara que existen, que estan aprobados por la direccion, y que el personal los conoce.

Marco operacional (op): Planificacion, control de acceso, explotacion, servicios externos, continuidad del servicio, monitorizacion del sistema. Aqui es donde vive la mayor parte del trabajo tecnico. Gestion de configuraciones, gestion de vulnerabilidades, proteccion frente a codigo danino, registro de actividad.

Medidas de proteccion (mp): Proteccion de las instalaciones, proteccion del personal, proteccion de los equipos, proteccion de las comunicaciones, proteccion de los soportes de informacion, proteccion de las aplicaciones informaticas, proteccion de la informacion, proteccion de los servicios.

El entregable del gap analysis

Un documento que para cada control indique:

Estado	Significado
Cumple	Control implementado y documentado
Cumple parcialmente	Implementado pero falta documentacion, o documentado pero falta implementacion
No cumple	No existe
No aplica	Justificacion de por que no aplica

En nuestra experiencia, una empresa tecnologica con buenas practicas de desarrollo pero sin foco explicito en ENS suele estar al 40-50% de cumplimiento. El cifrado en transito ya lo tiene (HTTPS en todo). La gestion de accesos basica existe (SSO, roles). Lo que falta tipicamente: documentacion formal, gestion de vulnerabilidades sistematica, registro de actividad centralizado, y los controles especificos de administracion publica.

Fase 2: Plan de adecuacion (semanas 3-5)

Con el gap analysis, el plan de adecuacion define las acciones para cerrar las brechas. No es un documento generico; es un plan con responsables, plazos y dependencias.

Priorizacion practica

No todos los controles cuestan igual. Nuestra recomendacion de secuencia:

Primero: documentacion fundacional. Politica de seguridad, normativa, roles y responsabilidades. Sin esto, nada de lo demas tiene marco. Coste: bajo. Tiempo: 1-2 semanas. Impacto: alto (desbloquea todo lo demas).

Segundo: gestion de accesos. Si ya tienes un IdP (Google Workspace, Azure AD, Okta), implementar MFA, revisar roles, configurar politicas de contrasenas, y documentarlo. Es el control mas visible en auditoria y el que mas solapamiento tiene con ISO 27001. Coste: medio. Tiempo: 2-4 semanas.

Tercero: registro y monitorizacion. Centralizar logs, configurar alertas, implementar un sistema de deteccion basico. No necesitas un SIEM empresarial para categoria media; Wazuh (open source) o el logging nativo de tu cloud provider cubren los requisitos. Coste: bajo-medio. Tiempo: 2-4 semanas.

Cuarto: gestion de vulnerabilidades. Escaneos periodicos (Trivy para contenedores, Nuclei o Nessus para infraestructura), proceso de parcheo documentado, y un registro de vulnerabilidades con seguimiento. Coste: bajo. Tiempo: 2-3 semanas.

Quinto: continuidad de servicio. Plan de continuidad, plan de recuperacion, pruebas documentadas. Si operas en cloud con infraestructura como codigo, la recuperacion es mas sencilla de demostrar. Coste: medio. Tiempo: 3-4 semanas.

El enemigo: la documentacion

Seamos honestos. Para la mayoria de los equipos de ingenieria, la documentacion de seguridad es el aspecto mas tedioso del ENS. Procedimientos de gestion de incidentes, planes de continuidad, politicas de uso aceptable, registros de revision de accesos. Hay que escribirlo, mantenerlo y demostrarlo.

Dos enfoques que funcionan:

Templates + adaptacion: El CCN-CERT publica guias (serie CCN-STIC) con plantillas para la mayoria de los documentos requeridos. No son perfectas, pero son un punto de partida que el auditor conoce y acepta. Adaptarlas a tu realidad es mas rapido que escribir desde cero.

Documentacion como codigo: Politicas y procedimientos en un repositorio Git, versionados, con pull requests para cambios. La fecha del commit es evidencia del historial de revisiones. El PR demuestra quien aprobo el cambio. No es el enfoque tradicional, pero los auditores modernos lo aceptan (y algunos lo prefieren).

Fase 3: Implementacion (meses 2-6)

La implementacion es donde el plan se convierte en realidad. Los controles tecnicos que mas trabajo requieren para empresas tecnologicas en cloud:

Gestion de configuraciones (op.exp.2)

El ENS exige que las configuraciones de los sistemas esten documentadas, controladas y auditables. Si ya usas Terraform, Ansible, Helm charts o similar, llevas el 80% hecho. Lo que falta:

• Una baseline de configuracion documentada para cada tipo de sistema.
• Un proceso de gestion de cambios que registre quien cambio que y cuando.
• Verificacion periodica de que la configuracion real coincide con la baseline.

Herramientas como AWS Config, Azure Policy o scripts de compliance propios cubren la verificacion. El punto clave: la infraestructura como codigo no solo es buena ingenieria; es evidencia de cumplimiento.

Proteccion frente a codigo danino (op.exp.6)

Antivirus en sentido tradicional no aplica a la mayoria de las empresas tecnologicas que operan en Linux/containers. Lo que si aplica:

• Escaneo de imagenes de contenedores en el pipeline de CI (Trivy, Snyk Container).
• Analisis estatico de dependencias (Dependabot, Renovate + auditorias de seguridad).
• Proteccion de endpoints en estaciones de trabajo de desarrollo (si usan macOS/Windows).

El auditor quiere ver que existe un proceso, que se ejecuta automaticamente, y que los hallazgos se gestionan.

Registro de actividad (op.exp.8)

Todo sistema en scope debe generar logs de actividad que registren: quien accedio, cuando, desde donde, y que hizo. Los logs deben almacenarse de forma segura (inmutables o protegidos contra manipulacion) durante el periodo definido en la politica de retencion.

Para una empresa en cloud, el enfoque practico:

• CloudTrail / Activity Log / Audit Log del cloud provider para operaciones de infraestructura.
• Logs de aplicacion estructurados (JSON) enviados a un sistema centralizado.
• Logs de acceso a datos sensibles con campos de negocio (que expediente, que datos).
• Retencion minima de 12 meses (el ENS no especifica un periodo exacto, pero 12 meses es la practica aceptada para categoria media).

Cifrado (mp.com, mp.info)

El ENS en categoria media exige cifrado en transito y recomienda cifrado en reposo. En la practica:

• TLS 1.2+ para todas las comunicaciones. Sin excepciones.
• Cifrado en reposo para bases de datos y almacenamiento. En cloud, activar la encriptacion nativa (RDS encryption, S3 server-side encryption).
• Gestion de claves: KMS del cloud provider o HashiCorp Vault. Las claves no deben estar hardcodeadas ni en repositorios.

Fase 4: Auditoria interna (mes 5-6)

La auditoria interna es obligatoria antes de la certificacion. Debe ser realizada por alguien independiente del equipo que implemento los controles. Puede ser un equipo interno de otra area o un consultor externo.

La auditoria interna tiene dos propositos:

1. Identificar no conformidades antes de que las encuentre el auditor externo. Es mas barato corregir un hallazgo interno que explicar uno en la auditoria de certificacion.
2. Generar evidencia de que el ciclo de mejora continua funciona. El auditor externo vera el informe de auditoria interna, las no conformidades identificadas, y las acciones correctivas. Eso demuestra madurez del sistema.

Consejo practico: no busques una auditoria interna limpia. Busca una auditoria interna que encuentre las cosas que hay que corregir. Una auditoria sin hallazgos genera mas sospechas que una con hallazgos gestionados.

Fase 5: Certificacion (mes 6-8)

La certificacion la realiza una entidad acreditada por ENAC (Entidad Nacional de Acreditacion). Hay una docena de entidades acreditadas para auditorias ENS en Espana.

Que esperar de la auditoria

El auditor revisara:

• Documentacion completa: Politica, normativa, procedimientos, plan de adecuacion, declaracion de aplicabilidad, analisis de riesgos, informe de auditoria interna.
• Evidencias tecnicas: Configuraciones reales, logs, resultados de escaneos, registros de acceso, pruebas de continuidad.
• Entrevistas: Hablara con el responsable de seguridad, con tecnicos, y posiblemente con personal no tecnico para verificar que la formacion es real.

No conformidades

Las no conformidades se clasifican en:

• Mayores: Ausencia total de un control requerido, o un control que no funciona en absoluto. Impiden la certificacion hasta que se corrigen.
• Menores: El control existe pero tiene deficiencias. Se puede obtener la certificacion con un plan de correccion.
• Observaciones: Sugerencias de mejora. No afectan a la certificacion.

En nuestra experiencia, las no conformidades mas comunes en empresas tecnologicas:

1. Falta de formacion documentada en seguridad para todo el personal.
2. Revision de accesos no periodicidad demostrable.
3. Plan de continuidad sin pruebas documentadas.
4. Gestion de proveedores sin evaluacion de seguridad formal.

Ninguna de estas es tecnica. Son de proceso y documentacion. Lo que refuerza el punto: la parte tecnica es la facil.

Coste y tiempo realista

Para una empresa tecnologica de 50-150 personas, con infraestructura en cloud y un nivel de madurez medio:

Concepto	Estimacion
Gap analysis + plan (consultoria)	5.000-15.000 EUR
Implementacion tecnica (interno)	2-4 meses de 1-2 personas
Documentacion (interno + consultoria)	8.000-20.000 EUR
Herramientas (SIEM, escaneo, compliance)	5.000-15.000 EUR/ano
Auditoria interna	3.000-8.000 EUR
Certificacion (auditor externo)	8.000-18.000 EUR
Total estimado	30.000-75.000 EUR
Tiempo total	6-8 meses

El rango es amplio porque depende enormemente del punto de partida. Una empresa con ISO 27001 puede certificarse en ENS en 3-4 meses por la mitad del coste. Una empresa sin ningun framework de seguridad formal necesitara el rango alto.

Despues de la certificacion

La certificacion ENS no es un proyecto; es un sistema de gestion continuo. Requiere:

• Revision anual del analisis de riesgos.
• Auditorias internas anuales.
• Actualizacion de procedimientos cuando cambian los sistemas.
• Formacion periodica del personal.
• Recertificacion cada 2 anos (categoria media).

El error mas comun post-certificacion: relajarse. El 30% de las empresas que se certifican tienen problemas en la recertificacion porque dejaron de mantener el sistema. Un servicio gestionado de compliance que mantenga el sistema vivo entre auditorias vale la inversion.

El ENS no es un destino. Es un punto de partida para una gestion de seguridad madura que, incidentalmente, abre las puertas del mercado publico y pavimenta el camino hacia ISO 27001 y SOC 2. Para conocer los nuevos requisitos ENS 2025 para proveedores cloud, revisa nuestro analisis reciente.