NIS2 Portugal

Artigo 21 da NIS2: Medidas de Gestão de Risco

Compreenda as 9 medidas mínimas obrigatórias de cibersegurança que todas as entidades NIS2 devem implementar

📋

O coração da NIS2: Artigo 21

O Artigo 21 da Diretiva NIS2 é o núcleo operacional da diretiva, estabelecendo as medidas mínimas de gestão de risco de cibersegurança que todas as entidades abrangidas devem obrigatoriamente implementar. Em Portugal, estas medidas estão transpostas no Art. 27.º do DL 125/2025 (Decreto-Lei n.º 125/2025, de 4 de dezembro). Estas medidas representam o patamar mínimo de maturidade em cibersegurança exigido por lei.

Ao contrário de frameworks voluntários como ISO 27001, estas medidas são requisitos legais obrigatórios. A sua não implementação pode resultar em sanções administrativas significativas, incluindo coimas de até €10 milhões ou 2% do volume de negócios global anual, consoante o que for superior.

As medidas aplicam-se tanto a entidades essenciais quanto a entidades importantes, embora a supervisão e penalidades sejam mais rigorosas para as primeiras. Todas as organizações devem implementar estas medidas de forma "apropriada e proporcional" aos riscos que enfrentam, dimensão da organização e criticidade dos serviços prestados.

Prazo de conformidade em Portugal: O DL 125/2025 entrou em vigor a 3 de abril de 2026. A conformidade com o Art. 27.º é obrigatória desde essa data. O prazo para nomeação do responsável de cibersegurança foi de 20 dias úteis após a entrada em vigor (até cerca de 4 de maio de 2026).

As 9 medidas mínimas de cibersegurança

Clique em cada medida para ver informação detalhada sobre implementação, evidências necessárias e boas práticas

📊 Obrigação Geral: Análise de Riscos e Segurança dos Sistemas de Informação (Art. 26.º)

Esta obrigação geral enquadra todas as 9 medidas do Art. 27.º — não constitui uma medida separada, mas sim o fundamento sobre o qual todas as medidas se baseiam.

💡 O que significa:

Estabelecer políticas formais e documentadas para identificar, analisar e gerir os riscos de cibersegurança que a organização enfrenta. Isto inclui criar um inventário completo de ativos de informação, identificar ameaças e vulnerabilidades, e determinar tratamentos apropriados baseados em risco.

🔧 Implementação prática:

  • Documentar metodologia de risk assessment: Escolher e documentar framework reconhecido (ISO 27005, NIST RMF, OCTAVE) para avaliação de riscos
  • Criar inventário de ativos: Registar todo hardware, software, dados, serviços cloud e classificar por criticidade (Crítico/Alto/Médio/Baixo)
  • Desenvolver matriz de risco: Identificar ameaças relevantes (ransomware, phishing, DDoS), vulnerabilidades existentes, probabilidade e impacto
  • Definir risk appetite: Estabelecer nível de risco aceitável aprovado pela gestão de topo
  • Revisões regulares: Atualizar análise de risco pelo menos anualmente ou quando há mudanças significativas (novos sistemas, fusões, novos regulamentos)
  • Dashboard executivo: Reportar riscos principais ao conselho de administração trimestralmente
Ferramentas recomendadas: ISO 27001 Annex A, NIST Cybersecurity Framework, ENISA Threat Landscape, plataformas GRC (ServiceNow, Archer, MetricStream)

🚨 Medida 1: Gestão de Incidentes

▼

💡 O que significa:

Capacidade de detetar, responder, recuperar e reportar incidentes de cibersegurança de forma coordenada e eficaz. Inclui procedimentos claros para classificar incidentes, escalar para equipas apropriadas, conter ameaças, erradicar malware, e notificar autoridades dentro dos prazos legais.

🔧 Implementação prática:

  • Criar Incident Response Plan (IRP): Documento detalhado com procedimentos passo-a-passo para diferentes cenários (ransomware, data breach, DDoS, insider threat)
  • Formar CSIRT (Computer Security Incident Response Team): Equipa interna ou externa com funções definidas (Incident Manager, Technical Lead, Communications, Legal)
  • Matriz de classificação de incidentes: Definir critérios claros para Crítico/Alto/Médio/Baixo e SLAs de resposta
  • Implementar ferramentas de deteção: SIEM (Security Information and Event Management), IDS/IPS, EDR, XDR para identificar anomalias
  • Procedimentos de notificação CNCS: Templates prontos para notificação em 24h (early warning), 72h (relatório detalhado), 24h após fim do impacto (notificação de cessação) e 30 dias úteis (relatório final)
  • Exercícios regulares: Tabletop exercises trimestrais e simulações técnicas (red team) anualmente
  • Log de incidentes: Registar TODOS os incidentes (mesmo menores) para análise de tendências
Prazos de notificação NIS2 (Art. 42.º a 44.º do DL 125/2025):
  • 24 horas (Art. 42.º, n.º 1): Early warning — notificação inicial de incidente significativo
  • 72 horas (Art. 42.º, n.º 3): Relatório detalhado com impacto, medidas tomadas, IoCs
  • 24 horas após fim do impacto (Art. 43.º, n.º 1): Notificação de fim de impacto significativo
  • 30 dias úteis (Art. 44.º, n.º 1): Relatório final com root cause analysis e lições aprendidas

📄 Evidências necessárias:

  • Plano de resposta a incidentes aprovado
  • Lista de membros do CSIRT com contactos 24/7
  • Log/registo de todos os incidentes (com classificação, impacto, ações tomadas)
  • Notificações enviadas ao CNCS (comprovativo de envio)
  • Relatórios post-mortem de incidentes significativos
  • Evidências de exercícios (atas, scenarios, resultados)

⚠️ Lacunas comuns:

  • IRP desatualizado ou genérico (não específico para a organização)
  • CSIRT não treinado ou sem contactos atualizados
  • Falha na notificação ao CNCS dentro dos prazos
  • Sem procedimentos de escalação claros
  • Incidentes não documentados adequadamente
  • Nunca testaram o plano (sem exercícios)

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

💼 Medida 2: Continuidade das Atividades e Gestão de Crises

▼

💡 O que significa:

Garantir que operações críticas de negócio podem continuar durante e após um incidente grave de cibersegurança. Inclui planeamento de continuidade, gestão de backups, recuperação de desastres, e capacidade de gerir crises que ameaçam a sobrevivência organizacional.

🔧 Implementação prática:

  • Business Impact Analysis (BIA): Identificar processos críticos e dependências. Determinar impacto financeiro, reputacional e operacional de indisponibilidade
  • Definir RTO e RPO: Recovery Time Objective (tempo máximo de inatividade aceitável) e Recovery Point Objective (perda máxima de dados aceitável) para cada sistema crítico
  • Business Continuity Plan (BCP): Estratégias para manter operações durante disrupções (trabalho remoto, site alternativo, processos manuais)
  • Disaster Recovery Plan (DRP): Procedimentos técnicos detalhados para recuperar sistemas IT após falha catastrófica
  • Estratégia de backup 3-2-1: 3 cópias de dados, em 2 meios diferentes, 1 offsite/offline (proteção contra ransomware)
  • Testes regulares: DR drill anual completo + testes de restore mensais + tabletop exercises trimestrais
  • Crisis Management Team: Equipa executiva para gerir crises que afetam toda a organização
Exemplo de RTO/RPO por criticidade:
  • Sistemas críticos: RTO 4h, RPO 15 minutos
  • Sistemas importantes: RTO 24h, RPO 1 hora
  • Sistemas normais: RTO 72h, RPO 24 horas

📄 Evidências necessárias:

  • Business Impact Analysis (BIA) atualizada
  • Business Continuity Plan (BCP) aprovado pela gestão
  • Disaster Recovery Plan (DRP) com runbooks por sistema
  • Matriz de RTO/RPO para todos os sistemas críticos
  • Logs de backups e evidência de testes de restore
  • Relatórios de DR drills e exercícios
  • Lista de sites alternativos ou acordos de contingência

⚠️ Lacunas comuns:

  • BCP/DRP nunca testados na prática
  • RTO/RPO não definidos ou irrealistas
  • Backups sem proteção contra ransomware (tudo online)
  • Testes de restore nunca executados
  • Runbooks técnicos desatualizados
  • Sem plano de comunicação de crise

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

🔗 Medida 3: Segurança da Cadeia de Fornecimento

▼

💡 O que significa:

Gerir riscos de cibersegurança provenientes de fornecedores, prestadores de serviços e parceiros que têm acesso aos sistemas ou dados da organização. A NIS2 reconhece que a segurança organizacional depende também da segurança da cadeia de fornecimento.

🔧 Implementação prática:

  • Inventário de fornecedores críticos: Identificar todos os vendors com acesso a sistemas/dados sensíveis (cloud providers, MSPs, software vendors, subcontratadores)
  • Risk assessment por fornecedor: Classificar cada fornecedor por nível de risco (Alto/Médio/Baixo) baseado em acesso, criticidade e volume de dados
  • Due diligence pré-contratual: Verificar certificações (ISO 27001, SOC 2), políticas de segurança, breach history, solidez financeira
  • Cláusulas contratuais de segurança: Requisitos obrigatórios de segurança, direito a auditoria, notificação de incidentes em 24h, SLAs de segurança, responsabilidade por breaches
  • Monitorização contínua: Auditorias periódicas, questionários de segurança anuais, revisão de relatórios SOC 2 Type II
  • Gestão de acessos de terceiros: Princípio do least privilege, MFA obrigatório, segregação de ambientes, logs de atividade
  • Plano de exit: Estratégia para recuperar dados e migrar serviços caso fornecedor falhe
Estatística alarmante: 60% das organizações sofreram data breaches devido a vulnerabilidades na cadeia de fornecimento. A NIS2 responsabiliza diretamente as organizações por falhas de segurança dos seus fornecedores.

📄 Evidências necessárias:

  • Inventário de fornecedores com classificação de risco
  • Avaliações de risco de fornecedores críticos
  • Contratos com cláusulas de segurança
  • Relatórios de auditorias a fornecedores
  • Certificações de fornecedores (ISO 27001, SOC 2)
  • Logs de acessos de terceiros
  • Notificações de incidentes recebidas de fornecedores

⚠️ Lacunas comuns:

  • Sem avaliação formal de risco de fornecedores
  • Contratos sem cláusulas de segurança adequadas
  • Nunca auditaram fornecedores críticos
  • Sem visibilidade sobre subcontratadores
  • Acessos de fornecedores sem MFA
  • Sem processo de monitorização contínua

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

🛡️ Medida 4: Segurança na Aquisição, Desenvolvimento e Manutenção de Sistemas

▼

💡 O que significa:

Integrar segurança em todo o ciclo de vida dos sistemas de informação - desde conceção, aquisição, desenvolvimento, até manutenção e desmantelamento. Princípio "Security by Design" e "Security by Default".

🔧 Implementação prática:

  • Secure SDLC: Integrar segurança em todas as fases (Requirements, Design, Development, Testing, Deployment, Maintenance)
  • Security requirements em procurement: RFPs devem incluir requisitos de segurança obrigatórios (encriptação, MFA, logging, compliance)
  • Threat modeling: Análise de ameaças durante fase de design (STRIDE, DREAD)
  • Secure coding standards: Guidelines por linguagem (OWASP Secure Coding Practices)
  • Code reviews obrigatórios: Peer review focado em segurança antes de merge
  • SAST/DAST: Static Application Security Testing (SonarQube, Checkmarx) e Dynamic (OWASP ZAP, Burp Suite)
  • Dependency scanning: Verificação automática de CVEs em bibliotecas (Snyk, Dependabot, WhiteSource)
  • Patch management rigoroso: Patches críticos em 24-48h, patches importantes em 7 dias
  • Penetration testing: Pentests anuais por entidade certificada (CREST, OSCP)
  • Configuration management: Hardening baseado em CIS Benchmarks ou DISA STIGs
DevSecOps pipeline ideal: Commit → SAST → Build → Dependency Scan → Container Scan → DAST → Deploy → Continuous Monitoring

📄 Evidências necessárias:

  • Secure SDLC documentado e aprovado
  • Secure coding guidelines por linguagem
  • Relatórios de code reviews
  • Relatórios de scans SAST/DAST
  • Relatórios de dependency scanning
  • Relatórios de penetration testing
  • Logs de patch management (evidência de aplicação atempada)
  • Baselines de configuração segura

⚠️ Lacunas comuns:

  • Segurança apenas considerada antes de go-live (não durante desenvolvimento)
  • Sem ferramentas automatizadas de security testing
  • Patches críticos aplicados com atraso (semanas/meses)
  • Dependências de terceiros nunca verificadas
  • Nunca fizeram penetration testing
  • Sistemas em produção sem hardening

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

🔍 Medida 5: Políticas e Procedimentos para Avaliar a Eficácia das Medidas

▼

💡 O que significa:

Monitorizar e medir se os controlos de segurança estão efetivamente a funcionar. Não basta implementar medidas - é necessário provar que são eficazes e melhorá-las continuamente.

🔧 Implementação prática:

  • Definir KPIs e KRIs de segurança:
    • KPIs: % sistemas patchados em 7 dias, % utilizadores com MFA, tempo médio de deteção de incidentes (MTTD), tempo médio de resposta (MTTR)
    • KRIs: Nº de incidentes críticos/mês, % phishing bem-sucedidos, nº vulnerabilidades críticas abertas
  • Auditorias internas: Auditorias trimestrais de controlos críticos (acessos, backups, patches)
  • Control testing: Testar efetividade de controlos (ex: phishing simulations para testar awareness, tentativas de bypass de MFA)
  • Executive dashboard: Dashboard executivo com KPIs/KRIs atualizado mensalmente
  • Maturity assessments: Avaliar maturidade global usando frameworks (NIST CSF levels, ISO 27001 maturity model)
  • Continuous monitoring: Monitorização contínua de controlos críticos com alertas automáticos
  • Gap analysis: Comparar estado atual vs. requisitos NIS2 e identificar lacunas
Exemplo de KPIs críticos:
  • Tempo médio para detetar incidente (MTTD): Target < 1 hora
  • Tempo médio para responder (MTTR): Target < 4 horas
  • % patches críticos aplicados em 48h: Target > 95%
  • % utilizadores com MFA ativado: Target = 100%

📄 Evidências necessárias:

  • Lista de KPIs/KRIs de cibersegurança definidos
  • Dashboard executivo (screenshots ou acesso)
  • Relatórios de auditorias internas
  • Resultados de control testing (ex: phishing simulation results)
  • Relatórios de maturity assessment
  • Atas de reuniões executivas onde segurança foi discutida

⚠️ Lacunas comuns:

  • KPIs nunca definidos ou medidos
  • Sem programa formal de auditoria interna
  • Controlos nunca testados para verificar eficácia
  • Gestão não recebe relatórios regulares
  • Métricas existem mas ninguém age sobre elas

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

🧹 Medida 6: Práticas de Higiene Cibernética e Formação em Cibersegurança

▼

💡 O que significa:

Garantir que todos os colaboradores têm conhecimento básico de cibersegurança e que a organização segue práticas fundamentais de higiene cibernética. A NIS2 exige especificamente formação OBRIGATÓRIA para órgãos de gestão.

🔧 Implementação prática:

  • Formação anual obrigatória: Security awareness training para 100% dos colaboradores (presencial ou e-learning com certificado)
  • Formação executiva OBRIGATÓRIA: NIS2 exige que órgãos de gestão recebam formação específica sobre riscos de cibersegurança e obrigações legais
  • Phishing simulations: Campanhas mensais de phishing simulado com follow-up training para quem falha
  • Formação role-based: Training específico por função (developers → secure coding, IT → hardening, HR → social engineering)
  • Campanhas de awareness: Posters, newsletters, screensavers sobre tópicos de segurança
  • Políticas de hygiene: Acceptable Use Policy, Clean Desk Policy, Password Policy, BYOD Policy
  • Inventário de ativos completo: CMDB (Configuration Management Database) atualizado
  • Hardening de sistemas: CIS Benchmarks aplicados, serviços desnecessários desativados
  • Antivirus + EDR: Endpoint Detection and Response em todos os endpoints
  • Centralização de logs: SIEM para agregar e analisar logs, retenção mínima 12 meses
Estatística crítica: 82% dos data breaches envolvem o elemento humano (Verizon DBIR 2024). Formação eficaz é linha de defesa fundamental.

📄 Evidências necessárias:

  • Registos de formação (quem, quando, que curso, certificados)
  • Certificados de formação executiva (OBRIGATÓRIO para gestão)
  • Resultados de phishing simulations
  • Políticas de acceptable use, passwords, clean desk
  • Inventário de ativos (CMDB)
  • Baselines de hardening (CIS Benchmarks aplicados)
  • Evidência de antivirus/EDR deployment
  • Logs centralizados com evidência de retenção adequada

⚠️ Lacunas comuns:

  • Formação genérica "off-the-shelf" sem contexto organizacional
  • Gestores de topo NÃO recebem formação (violação NIS2!)
  • Training uma vez e nunca mais (deve ser anual)
  • Phishing simulations sem follow-up training
  • Políticas existem mas não são comunicadas/enforced
  • Inventário de ativos desatualizado

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

🔐 Medida 7: Políticas sobre Utilização de Criptografia e Encriptação

▼

💡 O que significa:

Proteger confidencialidade e integridade de dados através de criptografia forte, tanto em trânsito (data-in-transit) como em repouso (data-at-rest). Inclui gestão segura de chaves criptográficas.

🔧 Implementação prática:

  • Política de encriptação: Documento formal definindo onde, quando e como usar encriptação
  • Data-in-transit:
    • TLS 1.2+ para todas as comunicações web (deprecar TLS 1.0/1.1)
    • VPN (IPsec ou WireGuard) para acesso remoto
    • Email encryption para dados sensíveis (S/MIME, PGP)
  • Data-at-rest:
    • Full-disk encryption em todos os laptops/desktops (BitLocker, LUKS, FileVault)
    • Database encryption (TDE - Transparent Data Encryption)
    • File server encryption
    • Backup encryption (com chaves DIFERENTES de produção)
  • Algoritmos aprovados: AES-256, RSA ≥ 2048 bits, ECDSA ≥ 256 bits. Evitar DES, 3DES, MD5, SHA-1
  • Key management: PKI interno ou cloud KMS (AWS KMS, Azure Key Vault). HSM para chaves críticas
  • Key rotation: Rotação de chaves anualmente ou após suspeita de compromisso
  • Certificate management: Inventário de certificados, renovação automática, monitoring de expiração
GDPR compliance: Encriptação de dados pessoais é considerada "pseudonimização" pelo GDPR, reduzindo obrigações de notificação de breaches.

📄 Evidências necessárias:

  • Política de encriptação aprovada
  • Inventário de dados encriptados (onde, como, que algoritmo)
  • Evidência de full-disk encryption deployment
  • Configuração de TLS 1.2+ em web servers
  • Documentação de key management procedures
  • Inventário de certificados digitais
  • Evidência de key rotation

⚠️ Lacunas comuns:

  • Encriptação inconsistente (alguns sistemas sim, outros não)
  • Usar algoritmos fracos ou deprecated (3DES, SHA-1)
  • Chaves armazenadas inseguramente (hardcoded, em plaintext)
  • Backups não encriptados
  • Certificados expirados ou self-signed em produção
  • Sem gestão centralizada de chaves

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

👥 Medida 8: Segurança dos Recursos Humanos e Políticas de Controlo de Acessos

▼

💡 O que significa:

Controlar rigorosamente quem tem acesso a quê, gerir o ciclo de vida de acessos dos colaboradores, e garantir que princípios de least privilege e segregation of duties são aplicados.

🔧 Implementação prática:

  • Princípio do Least Privilege: Cada utilizador/sistema tem APENAS os acessos estritamente necessários para a função
  • Role-Based Access Control (RBAC): Acessos atribuídos por função/role, não individualmente
  • Joiners/Movers/Leavers process:
    • Joiners: Acessos provisionados baseado em role aprovado
    • Movers: Revisão e ajuste de acessos quando muda de função
    • Leavers: Desativação IMEDIATA de todos os acessos no dia de saída
  • Access reviews: Revisão trimestral de todos os acessos (especialmente privilegiados). Gestores aprovam ou revogam
  • Privileged Access Management (PAM): Gestão rigorosa de contas admin/root com just-in-time access
  • Segregation of Duties (SoD): Separação de funções críticas (quem desenvolve ≠ quem aprova deploy)
  • Background checks: Verificação de antecedentes para posições sensíveis
  • NDAs e confidentiality agreements: Acordos de confidencialidade para todos os colaboradores
  • Asset management: Tracking de hardware, software licenses, dispositivos móveis
Zero Standing Privileges: Tendência moderna é eliminar acessos privilegiados permanentes. Admins recebem acesso elevado apenas quando necessário (JIT - Just-In-Time).

📄 Evidências necessárias:

  • Política de controlo de acessos
  • Matriz RBAC (roles e permissões)
  • Procedimento JML (Joiners/Movers/Leavers) documentado
  • Relatórios de access reviews (quem aprovou, o quê, quando)
  • Lista de contas privilegiadas
  • Logs de acessos privilegiados
  • Matriz de segregation of duties
  • Inventário de ativos (quem tem o quê)

⚠️ Lacunas comuns:

  • Contas órfãs (ex-colaboradores ainda ativos)
  • Access reviews nunca executadas
  • Privilégios excessivos (todos são admins)
  • Contas partilhadas (admin/root usadas por múltiplas pessoas)
  • Sem segregation of duties
  • Offboarding demorado (acessos ativos dias após saída)

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

🔑 Medida 9: Utilização de Autenticação Multi-Fator e Comunicações Seguras

▼

💡 O que significa:

Exigir pelo menos dois fatores independentes para autenticação (algo que sabe + algo que tem + algo que é) e garantir que todas as comunicações são realizadas através de canais seguros.

🔧 Implementação prática:

  • MFA OBRIGATÓRIO para:
    • 100% dos acessos remotos (VPN, cloud apps, webmail)
    • 100% das contas privilegiadas/administrativas (SEM EXCEÇÕES)
    • Sistemas críticos (ERP, CRM, bases de dados, financeiros)
    • Recomendado: Email para todos os utilizadores
  • Métodos MFA (por ordem de segurança):
    1. FIDO2/WebAuthn hardware keys (YubiKey, Titan) - mais seguro, phishing-resistant
    2. Authenticator apps (Microsoft/Google Authenticator, Authy)
    3. Push notifications (Duo, Microsoft Authenticator)
    4. SMS/Voice (menos seguro, vulnerável a SIM swapping)
  • Conditional Access: MFA adaptativo baseado em risco (localização anómala, dispositivo desconhecido, ação sensível)
  • Passwordless: Evolução para autenticação sem password (Windows Hello, passkeys FIDO2)
  • Comunicações seguras:
    • Messaging: Signal, WhatsApp, Teams com E2EE enabled
    • Video conferencing: Zoom/Teams com waiting rooms e passwords
    • Voice calls: Awareness sobre vishing (voice phishing)
  • MFA recovery process: Procedimento seguro para utilizadores que perdem acesso ao 2º fator
Eficácia comprovada: MFA bloqueia 99.9% dos ataques de credential stuffing e phishing básico (Microsoft Security Report 2024).

📄 Evidências necessárias:

  • Política de MFA aprovada
  • Registos de enrollment de MFA (% utilizadores com MFA)
  • Logs mostrando uso efetivo de MFA
  • Configuração de conditional access policies
  • Lista de ferramentas de comunicação aprovadas
  • Procedimento de MFA recovery

⚠️ Lacunas comuns:

  • MFA não enforced (opcional ou só alguns utilizadores)
  • Contas admin sem MFA (violação grave!)
  • Usar apenas SMS como 2º fator (vulnerável)
  • Comunicações internas por canais não encriptados
  • MFA bypass fácil ou recovery process inseguro

✅ Checklist de implementação

📊 Estado de implementação

📝 Notas de implementação

Princípio da proporcionalidade

As medidas devem ser "apropriadas e proporcionais" ao risco, dimensão e criticidade da organização

Pequenas organizações

  • Ferramentas mais simples e acessíveis (ex: Excel para risk register)
  • Revisões menos frequentes (anuais vs. trimestrais)
  • Menor profundidade documental
  • Podem usar serviços geridos (MSP, MSSP) para suprir gaps de expertise
  • Foco nas 9 medidas core sem complexidade excessiva

Grandes organizações / Críticas

  • Ferramentas sofisticadas (GRC platforms, SIEM enterprise, SOAR)
  • Monitorização contínua 24/7 com SOC
  • Documentação extensiva e auditorias frequentes
  • Equipas de segurança dedicadas (CISO, CSIRT, Security Architects)
  • Requisitos adicionais se classificadas como "essenciais"

Abordagem baseada em risco

  • Maior risco = controlos mais rigorosos
  • Sistemas críticos requerem RTO/RPO agressivos
  • Dados sensíveis exigem encriptação mais forte
  • Fornecedores críticos necessitam auditorias mais frequentes
  • Compensatory controls se controlos ideais não forem viáveis
Importante: "Proporcional" não significa "opcional". As 9 medidas são OBRIGATÓRIAS para todos. A proporcionalidade aplica-se à profundidade, frequência e sofisticação da implementação, não à obrigatoriedade.

Evidências esperadas por auditores

O que autoridades de supervisão e auditores irão solicitar para verificar conformidade

Medida Documentos Registos/Logs Testes
1. Incidentes IRP, Procedimentos CSIRT Log de incidentes, Notificações CNCS Tabletop exercises, Simulações
2. Continuidade BCP, DRP, BIA, RTO/RPO Logs de backup, Testes de restore DR drills anuais
3. Supply Chain Contratos, Avaliações de risco Notificações de fornecedores Auditorias a fornecedores
4. Secure SDLC SDLC documentado, Coding guidelines Logs de patches, Code reviews SAST/DAST reports, Pentests
5. Eficácia Lista de KPIs/KRIs Dashboard executivo Auditorias internas, Control testing
6. Formação Políticas (AUP, passwords), Cursos Registos de formação, Certificados Phishing simulations
7. Encriptação Política de encriptação, Key management Inventário de dados encriptados Key rotation, Certificate renewals
8. Acessos RH Política de acessos, Matriz RBAC, JML Logs de acessos privilegiados Access reviews trimestrais
9. MFA Política de MFA Registos de enrollment, Logs de uso MFA Conditional access policies

Consequências de não conformidade

A não implementação das medidas mínimas do Art. 21 da Diretiva NIS2 (transpostas pelo Art. 27.º do DL 125/2025) pode resultar em sanções administrativas severas:

  • Coimas até €10 milhões ou 2% do volume de negócios global anual (o que for superior) para entidades essenciais
  • Coimas até €7 milhões ou 1.4% do volume de negócios global anual para entidades importantes
  • Responsabilidade pessoal da gestão: Administradores podem ser responsabilizados individualmente por negligência grave
  • Suspensão temporária: Estados-Membros podem aplicar suspensão temporária de gestores
  • Publicação de infrações: Não conformidades graves podem ser tornadas públicas, causando danos reputacionais
  • Restrições operacionais: Autoridades podem impor limitações à prestação de serviços até conformidade ser atingida
Nota importante: As coimas não são a única consequência. Um incidente significativo devido a não conformidade pode resultar em perdas operacionais, danos reputacionais e ações judiciais de clientes afetados.

Recursos úteis

📚

Orientações técnicas ENISA

Guia oficial da ENISA sobre implementação técnica das medidas do Art. 21 da Diretiva NIS2 (Art. 27.º DL 125/2025)

Aceder →
🇵🇹

CNCS Portugal

Centro Nacional de Cibersegurança - autoridade nacional de supervisão NIS2

Aceder →
📝

Templates prontos

Modelos editáveis para IRP, BCP, políticas e mais

Ver templates →
🧮

Calculadora de conformidade

Descubra se está abrangido pela NIS2 e que medidas deve implementar

Calcular →
✅

Quiz de avaliação

Teste o seu nível de conformidade com as 9 medidas obrigatórias

Fazer quiz →
📖

Roadmap 90 dias

Roadmap passo-a-passo para atingir conformidade NIS2

Ver guia →

Perguntas frequentes

Qual é o prazo para implementar as medidas do Art. 21 (Art. 27.º DL 125/2025)?

▼

Em Portugal, a transposição foi concretizada pelo Decreto-Lei n.º 125/2025, publicado a 4 de dezembro de 2025, que entrou em vigor a 3 de abril de 2026 (120 dias após a publicação). As medidas do Art. 27.º do DL 125/2025 (correspondentes ao Art. 21 da Diretiva NIS2) são obrigatórias desde essa data. As autoridades nacionais (CNCS e autoridades setoriais) podem iniciar supervisão ativa e aplicar sanções por não conformidade.

Posso usar ISO 27001 para cumprir o Art. 21 (Art. 27.º DL 125/2025)?

▼

Sim, parcialmente. A ISO 27001 cobre a maioria das medidas do Art. 27.º do DL 125/2025 (Art. 21 da Diretiva NIS2), especialmente através do Annex A. No entanto, há diferenças:

  • NIS2 exige especificamente formação obrigatória para gestão de topo (não explícito em ISO 27001)
  • NIS2 tem prazos rígidos de notificação (24h/72h/24h fim impacto/30d úteis) não presentes em ISO 27001
  • NIS2 foca mais em segurança da cadeia de fornecimento
  • ISO 27001 é mais abrangente em alguns aspetos (mais controlos disponíveis)

Recomendação: Use ISO 27001 como framework base e adicione requisitos específicos NIS2.

Que evidências devo guardar para auditorias?

▼

Para cada medida, deve manter:

  • Políticas e procedimentos: Documentos formais aprovados pela gestão
  • Registos de implementação: Screenshots, configurações, deployment logs
  • Evidências de teste: Relatórios de DR drills, phishing simulations, pentests
  • Logs e registos: Logs de incidentes, backups, acessos, patches (mínimo 12 meses retenção)
  • Certificados e relatórios: Formações, auditorias, SOC 2 de fornecedores
  • Comunicações com autoridades: Notificações enviadas ao CNCS

Consulte a tabela "Evidências esperadas por auditores" acima para lista completa por medida.

Como reportar incidentes ao CNCS?

▼

O CNCS (Centro Nacional de Cibersegurança) disponibiliza plataforma online para notificação de incidentes. Procedimento (Art. 42.º a 44.º do DL 125/2025):

  1. 24 horas (Art. 42.º, n.º 1): Early warning via plataforma CNCS com informação mínima (tipo de incidente, data/hora, sistemas afetados)
  2. 72 horas (Art. 42.º, n.º 3): Relatório detalhado com impacto, medidas de contenção, IoCs, número de afetados
  3. 24 horas após fim do impacto (Art. 43.º, n.º 1): Notificação de fim de impacto — declaração de que o impacto significativo cessou e resumo das medidas de recuperação
  4. 30 dias úteis (Art. 44.º, n.º 1): Relatório final com root cause analysis, impacto final, lições aprendidas

Importante: Incidentes "significativos" DEVEM ser reportados. Critérios incluem: impacto operacional grave, compromisso de dados, +100k utilizadores afetados, ransomware.

Aceder à plataforma CNCS →

Pequenas empresas têm os mesmos requisitos?

▼

As 9 medidas são obrigatórias para TODAS as entidades abrangidas, independentemente da dimensão. No entanto, aplicam-se princípios de proporcionalidade:

  • Micro/pequenas empresas: Podem usar ferramentas mais simples (Excel vs. GRC platform), revisões menos frequentes, menor profundidade documental
  • Médias/grandes empresas: Ferramentas sofisticadas, monitorização 24/7, equipas dedicadas

Exemplo: Uma pequena empresa pode usar Excel para risk register e fazer backup para cloud; uma grande empresa precisa de plataforma GRC e datacenter secundário.

Importante: Proporcionalidade NÃO significa "opcional". A obrigatoriedade mantém-se - apenas a profundidade varia.

Precisa de ajuda com conformidade NIS2?

Utilize as nossas ferramentas gratuitas para avaliar o seu nível de conformidade e aceder a recursos práticos para implementação

Fazer quiz de avaliação Ver templates prontos

Recursos adicionais: