Compliance NIS2 em Portugal: Evidências em Vez de Documentação
O Decreto-Lei n.º 125/2025 entrou em vigor a 3 de abril de 2026. Portugal tem agora um dos enquadramentos de cibersegurança mais abrangentes da UE, e a maioria das organizações abrangidas não está preparada para aquilo que os auditores do CNCS vão realmente pedir.
A diferença não está entre organizações que conhecem a NIS2 e as que não conhecem. Está entre organizações que têm documentação e as que têm evidências de que os seus controlos funcionam em condições adversariais.
O Que o Artigo 27.º Exige Realmente
O Artigo 27.º do Decreto-Lei n.º 125/2025 exige que as entidades essenciais e importantes implementem medidas de gestão de risco de cibersegurança adequadas à sua dimensão, natureza e perfil de risco.
A expressão crítica é "avaliar a eficácia dos controlos de cibersegurança". Um registo de riscos construído a partir de entrevistas e questionários não satisfaz isto. Estes falham rotineiramente caminhos de movimento lateral que um projeto de segurança estruturado encontra nas primeiras duas horas. Uma política que afirma que contas privilegiadas exigem aprovação não significa nada se o Active Directory tem contas de serviço com permissões excessivas que nunca foram revistas. Planos de resposta a incidentes que nunca foram testados contra um cenário realista falham quando são precisos.
O que o Artigo 27.º pede é evidência de que os controlos resistem em condições de ataque realistas, não documentação de que existem.
O Que os Auditores Verificam
Os auditores da NIS2 esperam que as organizações demonstrem que testam cenários de ataque externos como um atacante real o faria, e riscos internos: o que alguém consegue fazer depois de entrar.
Na prática, os auditores do CNCS procuram:
- Um relatório de avaliação com âmbito definido que cubra os sistemas relevantes para as suas funções essenciais ou importantes. Apenas o perímetro externo é insuficiente. Rede interna, Active Directory, identidade cloud e acessos da supply chain são onde existem a maioria dos caminhos de ataque reais.
- Evidência de remediação: prova documentada de que os achados foram tratados após a avaliação. Um relatório sem registo de remediação é insuficiente para auditoria.
- Re-testes: evidência de que os controlos remediados foram validados depois de aplicadas as correções, não apenas marcados como resolvidos.
- Frequência de testes adequada ao perfil de risco da organização. Testes anuais para uma infraestrutura estática num setor de baixo risco podem ser suficientes. Mais frequentes para setores de alto risco com mudanças constantes.
Onde as Organizações em Portugal Estão a Falhar
As lacunas mais comuns em organizações abrangidas pela NIS2 não são firewalls em falta nem sistemas sem patches. São:
- Caminhos de ataque internos que ninguém mapeou. As avaliações externas passam. A rede interna nunca foi testada. Más configurações de Active Directory acumuladas ao longo de anos criam caminhos para acesso privilegiado que não exigem exploração de vulnerabilidades, apenas compreensão de como as permissões funcionam.
- Sistemas excluídos. Controlos de segurança nunca implementados em servidores legados por questões de compatibilidade. Sistemas clínicos, interfaces de controlo industrial e ambientes de processamento financeiro excluídos do âmbito de testes por razões operacionais. São precisamente os sistemas que mais importam e que os atacantes visam primeiro.
- Pontos cegos na supply chain. O Artigo 28.º estende obrigações de segurança a fornecedores terceiros de TIC. A maioria das organizações não avaliou o acesso que os seus managed service providers têm aos seus ambientes.
- Lacunas de responsabilização da gestão. A NIS2 torna a gestão diretamente responsável por aprovar e supervisionar as medidas de gestão de risco de cibersegurança. Quando ocorre uma violação de segurança e a investigação do CNCS revela que não houve testes estruturados, a responsabilidade fica ao nível da administração.
NIS2 vs DORA: Requisitos Diferentes
Para entidades financeiras (bancos, seguradoras, instituições de pagamento, empresas de investimento, prestadores de serviços de criptoativos), a DORA acrescenta requisitos para além da NIS2.
A DORA exige que as entidades financeiras realizem Threat-Led Penetration Testing pelo menos a cada três anos, com âmbito definido pelo regulador, conduzido em sistemas de produção reais e reportado à autoridade competente. Uma avaliação padrão satisfaz o nível básico de testes de TIC da DORA, mas não satisfaz os requisitos de TLPT.
TLPT é um projeto completo de red team conduzido por intelligence. O âmbito é definido externamente. A metodologia baseia-se em threat intelligence atual específica do setor financeiro. Os achados vão para o supervisor. O planeamento deve começar agora. Só a definição de âmbito, a recolha de threat intelligence e a coordenação com o regulador demoram meses.
| Requisito | NIS2 | DORA |
|---|---|---|
| Testes de segurança | Avaliações adequadas ao risco | TLPT a cada 3 anos no mínimo |
| Definição de âmbito | Definido pela organização | Definido pelo regulador |
| Ambiente de testes | Não especificado | Sistemas de produção reais |
| Reporte | Interno e ao CNCS a pedido | À autoridade competente |
| Base de threat intelligence | Recomendada | Obrigatória (metodologia TIBER-EU) |
| Supply chain | Obrigações do Artigo 28.º | Framework de risco de terceiros de TIC |
Como São os Testes de Nível de Compliance
Os reguladores e as autoridades nacionais competentes tratam cada vez mais os relatórios de avaliação de segurança como evidência-chave de preparação para o compliance da NIS2. O mínimo é claro: as organizações têm de testar, documentar e remediar.
Uma avaliação que satisfaz os requisitos do Artigo 27.º tem as seguintes características:
- Metodologia conduzida por operadores. Os scanners automáticos produzem listas de CVEs. Não encontram os caminhos de ataque no Active Directory, os roles IAM mal configurados nem os problemas de controlo de acessos que representam risco real de negócio.
- Âmbito relevante. Rede interna e infraestrutura de identidade, não apenas o perímetro externo. Ambientes cloud, se aplicável. Pontos de acesso da supply chain.
- Priorização por impacto de negócio. Achados mapeados para o impacto real nas operações, não apenas para o score de severidade. Um achado crítico num servidor de desenvolvimento isolado é menos urgente do que um problema de severidade média que fornece um caminho para acesso privilegiado em sistemas de produção.
- Tracking de remediação. Um registo que um auditor consegue rever. Achados tratados, re-testados e fechados antes do próximo ciclo de avaliação.
Prazos-Chave
| Prazo | Obrigação |
|---|---|
| 3 de abril de 2026 | Lei em vigor |
| 4 de maio de 2026 | Responsável de cibersegurança nomeado e comunicado ao CNCS |
| 4 de maio de 2026 | Ponto de contacto permanente 24/7 comunicado ao CNCS |
| 60 dias após o lançamento da plataforma do CNCS | Autoqualificação e registo |
| Até 24 meses após a entrada em vigor | Medidas completas de gestão de risco do Artigo 27.º |
A janela de 24 meses não significa que as organizações têm dois anos antes de agir. A supervisão do CNCS está ativa agora. O regime de coimas (multas até 10 milhões de euros ou 2% do volume de negócios anual global) aplica-se desde a data de entrada em vigor.
A OFFCEPT conduz pentests e operações de red team para organizações em setores abrangidos pela NIS2 em Portugal e na Europa. Os nossos projetos produzem relatórios de nível de compliance estruturados para auditorias do CNCS: achados com âmbito definido, mapeamento de impacto de negócio e evidência de remediação num formato que os auditores reconhecem.
Contacte-nos em contact@offcept.com.
Este artigo é meramente informativo e não constitui aconselhamento jurídico. Para orientação específica sobre as obrigações legais da sua organização, consulte um profissional jurídico qualificado.
Fontes: Decreto-Lei n.º 125/2025, CNCS (cncs.gov.pt), Diretiva (UE) 2022/2555, ENISA Technical Implementation Guidance v1.0.