ENS para empresas tecnológicas: guía práctica de certificación
Por qué el ENS importa ahora
El Esquema Nacional de Seguridad ya no es solo para la administración pública. Desde la actualización del Real Decreto 311/2022, cualquier empresa tecnológica que preste servicios al sector público español — o que aspire a hacerlo — necesita certificarse. Y el mercado lo ha notado: los pliegos de contratación pública incluyen cada vez más el ENS como requisito, no como mérito.
Para una empresa tecnológica de 30-200 personas, la certificación ENS puede parecer un ejercicio burocrático. No lo es, o no debería serlo. Bien ejecutado, el proceso ordena la seguridad de la organización y genera un marco reutilizable para otras certificaciones (ISO 27001, SOC 2). Mal ejecutado, es un proyecto de documentación que se desactualiza el día después de la auditoría.
Esta guía asume que tu empresa es un proveedor tecnológico (desarrollo de software, cloud, datos, consultoría) que necesita certificación ENS en categoría media. Es el escenario más común y el que más matices tiene.
Fase 1: Gap analysis (semanas 1-3)
El gap analysis es la fase que más equipos quieren saltar y la que más valor aporta. Sin saber dónde estás, no puedes planificar dónde necesitas llegar.
Qué evaluar
El ENS en categoría media exige 55 medidas de seguridad agrupadas en tres marcos:
Marco organizativo (org): Política de seguridad, normativa de seguridad, procedimientos operativos, proceso de autorización. Son documentos, pero no documentos vacíos. El auditor verificará que existen, que están aprobados por la dirección, y que el personal los conoce.
Marco operacional (op): Planificación, control de acceso, explotación, servicios externos, continuidad del servicio, monitorización del sistema. Aquí es donde vive la mayor parte del trabajo técnico. Gestión de configuraciones, gestión de vulnerabilidades, protección frente a código dañino, registro de actividad.
Medidas de protección (mp): Protección de las instalaciones, protección del personal, protección de los equipos, protección de las comunicaciones, protección de los soportes de información, protección de las aplicaciones informáticas, protección de la información, protección 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 documentación, o documentado pero falta implementación |
| No cumple | No existe |
| No aplica | Justificación de por qué no aplica |
En nuestra experiencia, una empresa tecnológica con buenas prácticas de desarrollo pero sin foco explícito en ENS suele estar al 40-50% de cumplimiento. El cifrado en tránsito ya lo tiene (HTTPS en todo). La gestión de accesos básica existe (SSO, roles). Lo que falta típicamente: documentación formal, gestión de vulnerabilidades sistemática, registro de actividad centralizado, y los controles específicos de administración pública.
Fase 2: Plan de adecuación (semanas 3-5)
Con el gap analysis, el plan de adecuación define las acciones para cerrar las brechas. No es un documento genérico; es un plan con responsables, plazos y dependencias.
Priorización práctica
No todos los controles cuestan igual. Nuestra recomendación de secuencia:
Primero: documentación fundacional. Política de seguridad, normativa, roles y responsabilidades. Sin esto, nada de lo demás tiene marco. Coste: bajo. Tiempo: 1-2 semanas. Impacto: alto (desbloquea todo lo demás).
Segundo: gestión de accesos. Si ya tienes un IdP (Google Workspace, Azure AD, Okta), implementar MFA, revisar roles, configurar políticas de contraseñas, y documentarlo. Es el control más visible en auditoría y el que más solapamiento tiene con ISO 27001. Coste: medio. Tiempo: 2-4 semanas.
Tercero: registro y monitorización. Centralizar logs, configurar alertas, implementar un sistema de detección básico. No necesitas un SIEM empresarial para categoría media; Wazuh (open source) o el logging nativo de tu cloud provider cubren los requisitos. Coste: bajo-medio. Tiempo: 2-4 semanas.
Cuarto: gestión de vulnerabilidades. Escaneos periódicos (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 recuperación, pruebas documentadas. Si operas en cloud con infraestructura como código, la recuperación es más sencilla de demostrar. Coste: medio. Tiempo: 3-4 semanas.
El enemigo: la documentación
Seamos honestos. Para la mayoría de los equipos de ingeniería, la documentación de seguridad es el aspecto más tedioso del ENS. Procedimientos de gestión de incidentes, planes de continuidad, políticas de uso aceptable, registros de revisión de accesos. Hay que escribirlo, mantenerlo y demostrarlo.
Dos enfoques que funcionan:
Templates + adaptación: El CCN-CERT publica guías (serie CCN-STIC) con plantillas para la mayoría de los documentos requeridos. No son perfectas, pero son un punto de partida que el auditor conoce y acepta. Adaptarlas a tu realidad es más rápido que escribir desde cero.
Documentación como código: Políticas 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 quién aprobó el cambio. No es el enfoque tradicional, pero los auditores modernos lo aceptan (y algunos lo prefieren).
Fase 3: Implementación (meses 2-6)
La implementación es donde el plan se convierte en realidad. Los controles técnicos que más trabajo requieren para empresas tecnológicas en cloud:
Gestión de configuraciones (op.exp.2)
El ENS exige que las configuraciones de los sistemas estén documentadas, controladas y auditables. Si ya usas Terraform, Ansible, Helm charts o similar, llevas el 80% hecho. Lo que falta:
- Una baseline de configuración documentada para cada tipo de sistema.
- Un proceso de gestión de cambios que registre quién cambió que y cuándo.
- Verificación periódica de que la configuración real coincide con la baseline.
Herramientas como AWS Config, Azure Policy o scripts de compliance propios cubren la verificación. El punto clave: la infraestructura como código no solo es buena ingeniería; es evidencia de cumplimiento.
Protección frente a código dañino (op.exp.6)
Antivirus en sentido tradicional no aplica a la mayoría de las empresas tecnológicas que operan en Linux/containers. Lo que si aplica:
- Escaneo de imágenes de contenedores en el pipeline de CI (Trivy, Snyk Container).
- Análisis estático de dependencias (Dependabot, Renovate + auditorías de seguridad).
- Protección de endpoints en estaciones de trabajo de desarrollo (si usan macOS/Windows).
El auditor quiere ver que existe un proceso, que se ejecuta automáticamente, y que los hallazgos se gestionan.
Registro de actividad (op.exp.8)
Todo sistema en scope debe generar logs de actividad que registren: quién accedió, cuándo, desde dónde, y qué hizo. Los logs deben almacenarse de forma segura (inmutables o protegidos contra manipulación) durante el periodo definido en la política de retención.
Para una empresa en cloud, el enfoque práctico:
- CloudTrail / Activity Log / Audit Log del cloud provider para operaciones de infraestructura.
- Logs de aplicación estructurados (JSON) enviados a un sistema centralizado.
- Logs de acceso a datos sensibles con campos de negocio (qué expediente, qué datos).
- Retención mínima de 12 meses (el ENS no especifica un periodo exacto, pero 12 meses es la práctica aceptada para categoría media).
Cifrado (mp.com, mp.info)
El ENS en categoría media exige cifrado en tránsito y recomienda cifrado en reposo. En la práctica:
- TLS 1.2+ para todas las comunicaciones. Sin excepciones.
- Cifrado en reposo para bases de datos y almacenamiento. En cloud, activar la encriptación nativa (RDS encryption, S3 server-side encryption).
- Gestión de claves: KMS del cloud provider o HashiCorp Vault. Las claves no deben estar hardcodeadas ni en repositorios.
Fase 4: Auditoría interna (mes 5-6)
La auditoría interna es obligatoria antes de la certificación. Debe ser realizada por alguien independiente del equipo que implementó los controles. Puede ser un equipo interno de otra área o un consultor externo.
La auditoría interna tiene dos propósitos:
- Identificar no conformidades antes de que las encuentre el auditor externo. Es más barato corregir un hallazgo interno que explicar uno en la auditoría de certificación.
- Generar evidencia de que el ciclo de mejora continua funciona. El auditor externo verá el informe de auditoría interna, las no conformidades identificadas, y las acciones correctivas. Eso demuestra madurez del sistema.
Consejo práctico: no busques una auditoría interna limpia. Busca una auditoría interna que encuentre las cosas que hay que corregir. Una auditoría sin hallazgos genera más sospechas que una con hallazgos gestionados.
Fase 5: Certificación (mes 6-8)
La certificación la realiza una entidad acreditada por ENAC (Entidad Nacional de Acreditación). Hay una docena de entidades acreditadas para auditorías ENS en España.
Qué esperar de la auditoría
El auditor revisará:
- Documentación completa: Política, normativa, procedimientos, plan de adecuación, declaración de aplicabilidad, análisis de riesgos, informe de auditoría interna.
- Evidencias técnicas: Configuraciones reales, logs, resultados de escaneos, registros de acceso, pruebas de continuidad.
- Entrevistas: Hablará con el responsable de seguridad, con técnicos, y posiblemente con personal no técnico para verificar que la formación 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 certificación hasta que se corrigen.
- Menores: El control existe pero tiene deficiencias. Se puede obtener la certificación con un plan de corrección.
- Observaciones: Sugerencias de mejora. No afectan a la certificación.
En nuestra experiencia, las no conformidades más comunes en empresas tecnológicas:
- Falta de formación documentada en seguridad para todo el personal.
- Revisión de accesos no periodicidad demostrable.
- Plan de continuidad sin pruebas documentadas.
- Gestión de proveedores sin evaluación de seguridad formal.
Ninguna de estas es técnica. Son de proceso y documentación. Lo que refuerza el punto: la parte técnica es la fácil.
Coste y tiempo realista
Para una empresa tecnológica de 50-150 personas, con infraestructura en cloud y un nivel de madurez medio:
| Concepto | Estimación |
|---|---|
| Gap analysis + plan (consultoría) | 5.000-15.000 EUR |
| Implementación técnica (interno) | 2-4 meses de 1-2 personas |
| Documentación (interno + consultoría) | 8.000-20.000 EUR |
| Herramientas (SIEM, escaneo, compliance) | 5.000-15.000 EUR/año |
| Auditoría interna | 3.000-8.000 EUR |
| Certificación (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 ningún framework de seguridad formal necesitará el rango alto.
Después de la certificación
La certificación ENS no es un proyecto; es un sistema de gestión continuo. Requiere:
- Revisión anual del análisis de riesgos.
- Auditorías internas anuales.
- Actualización de procedimientos cuando cambian los sistemas.
- Formación periódica del personal.
- Recertificación cada 2 años (categoría media).
El error más común post-certificación: relajarse. El 30% de las empresas que se certifican tienen problemas en la recertificación porque dejaron de mantener el sistema. Un servicio gestionado de compliance que mantenga el sistema vivo entre auditorías vale la inversión.
El ENS no es un destino. Es un punto de partida para una gestión de seguridad madura que, incidentalmente, abre las puertas del mercado público y pavimenta el camino hacia ISO 27001 y SOC 2. Para conocer los nuevos requisitos ENS 2025 para proveedores cloud, revisa nuestro análisis reciente.