Compliance NIS2 en Portugal: Evidencias en Vez de Documentación
El Decreto-Ley 125/2025 entró en vigor el 3 de abril de 2026. Portugal tiene ahora uno de los marcos de ciberseguridad más completos de la UE, y la mayoría de las organizaciones incluidas en su ámbito no están preparadas para lo que los auditores del CNCS van a pedir realmente.
La diferencia no está entre organizaciones que conocen la NIS2 y las que no. Está entre organizaciones que tienen documentación y las que tienen evidencias de que sus controles funcionan en condiciones adversariales.
Lo Que el Artículo 27 Exige Realmente
El Artículo 27 del Decreto-Ley 125/2025 exige que las entidades esenciales e importantes implementen medidas de gestión del riesgo de ciberseguridad adecuadas a su tamaño, naturaleza y perfil de riesgo.
La expresión crítica es "evaluar la eficacia de los controles de ciberseguridad". Un registro de riesgos construido a partir de entrevistas y cuestionarios no lo satisface. Estos pasan por alto de forma rutinaria rutas de movimiento lateral que un proyecto de seguridad estructurado encuentra en las primeras dos horas. Una política que afirma que las cuentas privilegiadas requieren aprobación no significa nada si Active Directory tiene cuentas de servicio con permisos excesivos que nunca se revisaron. Los planes de respuesta a incidentes que nunca se han probado contra un escenario realista fallan cuando se necesitan.
Lo que el Artículo 27 pide es evidencia de que los controles resisten en condiciones de ataque realistas, no documentación de que existen.
Lo Que Comprueban los Auditores
Los auditores de NIS2 esperan que las organizaciones demuestren que prueban escenarios de ataque externos como lo haría un atacante real, y riesgos internos: qué puede hacer alguien una vez dentro.
En la práctica, los auditores del CNCS buscarán:
- Un informe de evaluación con alcance definido que cubra los sistemas relevantes para sus funciones esenciales o importantes. Solo el perímetro externo es insuficiente. Red interna, Active Directory, identidad cloud y accesos de la supply chain son donde existen la mayoría de las rutas de ataque reales.
- Evidencia de remediación: prueba documentada de que los hallazgos se abordaron tras la evaluación. Un informe sin registro de remediación es insuficiente para una auditoría.
- Re-pruebas: evidencia de que los controles remediados se validaron después de aplicar las correcciones, no solo marcados como resueltos.
- Frecuencia de pruebas adecuada al perfil de riesgo de la organización. Pruebas anuales para una infraestructura estática en un sector de bajo riesgo pueden ser suficientes. Más frecuentes para sectores de alto riesgo con cambios constantes.
Dónde Están Fallando las Organizaciones en Portugal
Las lagunas más comunes en organizaciones cubiertas por NIS2 no son firewalls ausentes ni sistemas sin parches. Son:
- Rutas de ataque internas que nadie ha mapeado. Las evaluaciones externas pasan. La red interna nunca se ha probado. Malas configuraciones de Active Directory acumuladas durante años crean rutas hacia acceso privilegiado que no requieren explotar vulnerabilidades, solo entender cómo funcionan los permisos.
- Sistemas excluidos. Controles de seguridad nunca desplegados en servidores heredados por cuestiones de compatibilidad. Sistemas clínicos, interfaces de control industrial y entornos de procesamiento financiero excluidos del alcance de pruebas por razones operativas. Son precisamente los sistemas que más importan y a los que los atacantes apuntan primero.
- Puntos ciegos en la supply chain. El Artículo 28 extiende las obligaciones de seguridad a proveedores terceros de TIC. La mayoría de las organizaciones no ha evaluado el acceso que sus managed service providers tienen a sus entornos.
- Lagunas de responsabilidad de la dirección. NIS2 hace a la dirección directamente responsable de aprobar y supervisar las medidas de gestión del riesgo de ciberseguridad. Cuando ocurre una brecha de seguridad y la investigación del CNCS revela que no hubo pruebas estructuradas, la responsabilidad queda a nivel del consejo.
NIS2 vs DORA: Requisitos Diferentes
Para entidades financieras (bancos, aseguradoras, instituciones de pago, empresas de inversión, proveedores de servicios de criptoactivos), DORA añade requisitos que van más allá de NIS2.
DORA exige que las entidades financieras realicen Threat-Led Penetration Testing como mínimo cada tres años, con alcance definido por el regulador, conducido sobre sistemas de producción reales y reportado a la autoridad competente. Una evaluación estándar satisface el nivel básico de pruebas TIC de DORA, pero no satisface los requisitos de TLPT.
TLPT es un proyecto completo de red team dirigido por intelligence. El alcance se define externamente. La metodología se basa en threat intelligence actual específica del sector financiero. Los hallazgos van al supervisor. La planificación debería empezar ya. Solo la definición del alcance, la recopilación de threat intelligence y la coordinación con el regulador tardan meses.
| Requisito | NIS2 | DORA |
|---|---|---|
| Pruebas de seguridad | Evaluaciones adecuadas al riesgo | TLPT cada 3 años como mínimo |
| Definición de alcance | Definida por la organización | Definida por el regulador |
| Entorno de pruebas | No especificado | Sistemas de producción reales |
| Reporte | Interno y al CNCS a petición | A la autoridad competente |
| Base de threat intelligence | Recomendada | Obligatoria (metodología TIBER-EU) |
| Supply chain | Obligaciones del Artículo 28 | Framework de riesgo de terceros TIC |
Cómo Son las Pruebas de Nivel de Compliance
Los reguladores y las autoridades nacionales competentes tratan cada vez más los informes de evaluación de seguridad como evidencia clave de preparación para el compliance de NIS2. El mínimo es claro: las organizaciones deben probar, documentar y remediar.
Una evaluación que satisface los requisitos del Artículo 27 tiene las siguientes características:
- Metodología conducida por operadores. Los scanners automáticos producen listas de CVEs. No encuentran las rutas de ataque en Active Directory, los roles IAM mal configurados ni los problemas de control de acceso que representan riesgo real de negocio.
- Alcance relevante. Red interna e infraestructura de identidad, no solo el perímetro externo. Entornos cloud si aplica. Puntos de acceso de la supply chain.
- Priorización por impacto de negocio. Hallazgos mapeados al impacto real en operaciones, no solo al score de severidad. Un hallazgo crítico en un servidor de desarrollo aislado es menos urgente que un problema de severidad media que proporciona una ruta hacia acceso privilegiado en sistemas de producción.
- Tracking de remediación. Un registro que un auditor puede revisar. Hallazgos abordados, re-probados y cerrados antes del siguiente ciclo de evaluación.
Plazos Clave
| Plazo | Obligación |
|---|---|
| 3 de abril de 2026 | Ley en vigor |
| 4 de mayo de 2026 | Responsable de ciberseguridad designado y notificado al CNCS |
| 4 de mayo de 2026 | Punto de contacto permanente 24/7 notificado al CNCS |
| 60 días tras el lanzamiento de la plataforma del CNCS | Auto-calificación y registro |
| Hasta 24 meses tras la entrada en vigor | Medidas completas de gestión de riesgo del Artículo 27 |
La ventana de 24 meses no significa que las organizaciones tengan dos años antes de actuar. La supervisión del CNCS está activa ahora. El régimen sancionador (multas de hasta 10 millones de euros o el 2% de la facturación anual global) se aplica desde la fecha de entrada en vigor.
OFFCEPT conduce pentests y operaciones de red team para organizaciones en sectores cubiertos por NIS2 en Portugal y Europa. Nuestros proyectos producen reportes de nivel de compliance estructurados para auditorías del CNCS: hallazgos con alcance definido, mapeo de impacto de negocio y evidencia de remediación en un formato que los auditores reconocen.
Contáctanos en contact@offcept.com.
Este artículo es meramente informativo y no constituye asesoramiento legal. Para orientación específica sobre las obligaciones legales de tu organización, consulta a un profesional jurídico cualificado.
Fuentes: Decreto-Ley n.º 125/2025, CNCS (cncs.gov.pt), Directiva (UE) 2022/2555, ENISA Technical Implementation Guidance v1.0.