Cibersegurança para PME 2026 — o mínimo viável para a NIS2.

Resposta direta: o mínimo viável de segurança

O art.27.º do DL 125/2025 define nove áreas de medidas de cibersegurança para entidades em âmbito NIS2; somando a política de análise de riscos e de segurança dos sistemas (art. 29.º do DL e art. 21.º, n.º 2, alínea a), da Diretiva), são as dez abaixo. Tornam-se exigíveis em junho de 2028 (art. 10.º, n.º 2), mas não há interpretação: são estas, documentadas e demonstráveis ao CNCS quando solicitado. O mínimo viável não é implementar tudo de forma perfeita no ano zero — é ter cada uma das dez endereçada com evidência real, não só com intenção declarada.

1. Políticas de segurança das redes e dos sistemas de informação. Um documento formal, aprovado pela gestão, com âmbito, responsabilidades e períodos de revisão. Dez a quinze páginas chegam para uma PME — o que importa é estar aprovado, datado e com nome do aprovador.
2. Gestão de incidentes. Deteção, classificação, escalada e notificação. A cadeia de notificação ao CNCS tem prazos legais definidos: notificação inicial em ≤24 horas após a verificação do incidente significativo, atualização até 72 horas quando necessário, notificação do fim do impacto em ≤24 horas e relatório final em 30 dias úteis (arts. 42.º a 44.º). A cadeia tem de estar documentada e testada — não apenas escrita numa gaveta.
3. Continuidade do negócio e gestão de crises. Backups testados com RPO e RTO definidos, plano de recuperação e protocolo de gestão de crise. Não basta ter backup: é preciso documentar que a restauração foi testada, com data e resultado. Uma restauração por trimestre, registada, cobre o requisito de demonstração.
4. Segurança da cadeia de abastecimento. Inventário dos fornecedores críticos — cloud, outsourcing de TI, software ERP, integradoras — com avaliação mínima de risco por fornecedor. Não é uma auditoria completa a cada um: é ter um processo documentado para identificar e tratar riscos de terceiros.
5. Segurança na aquisição, desenvolvimento e manutenção de sistemas. Política de gestão de patches e atualizações, processo de gestão de vulnerabilidades, e requisitos mínimos de segurança para novos sistemas ou contratos de software. Aplicar o patch de vulnerabilidades críticas em prazo curto (≤30 dias é uma referência comum de boa prática) é o indicador operacional que demonstra o processo a funcionar.
6. Avaliação da eficácia das medidas de segurança. Pelo menos uma revisão anual documentada das medidas implementadas — pode ser uma autoavaliação interna estruturada ou uma auditoria externa. O que conta é ter o resultado documentado e o plano de remediação derivado.
7. Ciberhigiene básica e formação. Registo de formação em cibersegurança para toda a equipa. Uma sessão anual documentada cobre o requisito mínimo — o conteúdo tem de cobrir phishing, passwords seguras, MFA e o processo de notificação interna de incidentes.
8. Políticas e procedimentos de criptografia. Definir onde se usa criptografia, com que padrões (referência: AES-256 para dados em repouso, TLS 1.2+ para dados em trânsito) e quem gere as chaves. Inclui política para dispositivos móveis e laptops — encriptação de disco obrigatória para equipamentos com dados da empresa.
9. Segurança de recursos humanos, controlo de acessos e gestão de ativos. Política de acessos baseada no princípio do mínimo privilégio, processo formal de onboarding/offboarding de utilizadores (boa prática: remover os acessos no próprio dia da saída) e inventário de ativos de rede e sistemas. O inventário de ativos tem prazo legal específico — ver secção seguinte.
10. Autenticação multi-fator (MFA) e comunicações seguras. MFA obrigatório — não como recomendação, como controlo técnico ativo — para todos os acessos a email corporativo, sistemas críticos e acesso remoto. É o controlo com maior impacto na redução de incidentes e com verificação mais direta por parte do CNCS.

O mínimo viável é ter os dez endereçados com evidência. Uma PME com os dez documentados e os críticos implementados tecnicamente — especialmente MFA, backups testados e gestão de patches — está em posição substancialmente melhor do que uma com certificação ISO 27001 em curso mas sem política aprovada nem MFA ativo.

Os controlos que o CNCS pede primeiro

O CNCS começa por verificar o que tem prazo legal e evidência direta. Há três camadas com prazos definidos no DL 125/2025 (Regime Jurídico da Cibersegurança) e no Regulamento 756/2026:

Registo MyCiber: primeiro passo e prazos

Se a entidade não se registou até 15 de setembro de 2026, o que fazer agora está em MyCiber: o prazo passou, a obrigação não.

A autoidentificação no MyCiber (myciber.gov.pt) é o primeiro passo — precede a qualificação, não a segue. O prazo conta a partir da disponibilização da plataforma (23 de junho de 2026) e distingue-se pela antiguidade da entidade, não pela sua criticidade: 60 dias úteis para entidades já em atividade e 30 dias a contar do início de atividade para as entidades que a iniciem depois (RJC art. 8.º, n.º 1). Feita a autoidentificação, segue-se um período de audiência dos interessados de 10 dias úteis (Regulamento art.9.º) e só depois o CNCS emite a decisão de qualificação, com o nível de conformidade (básico, substancial ou elevado) e as medidas obrigatórias. Sem autoidentificação não existe base para demonstrar conformidade — é o primeiro ponto de verificação em qualquer contacto com a autoridade.

Para as entidades já em atividade, o prazo terminou a 15 de setembro de 2026 — a data da comunicação oficial do Governo, que conta 60 dias úteis (o texto do art. 8.º fala em 60 dias). Segundo o CNCS, a obrigação de registo não se extingue com o prazo: quem ainda não se autoidentificou continua obrigado a fazê-lo e deve fazê-lo de imediato.

Nomeação do responsável de segurança

O responsável de segurança tem de ser nomeado e comunicado ao CNCS em 20 dias úteis após qualificação (art. 31.º do DL 125/2025 e art. 14.º do Regulamento 756/2026). Tem de ser interno: titular dos órgãos de gestão, direção ou administração, ou alguém que lhes responda organicamente e de forma direta (art. 31.º, n.º 1). Uma PME sem equipa de segurança dedicada pode entregar a um prestador de serviços o ponto de contacto permanente e o trabalho técnico, mas não o papel de responsável. O responsável tem de ter autoridade real sobre as decisões de segurança, não ser apenas um nome no papel.

Inventário de ativos

O prazo para submeter a lista de ativos é 31 de janeiro do ano seguinte à qualificação ou 6 meses após qualificação — o que ocorrer primeiro. A lista, feita a partir do inventário, cobre os ativos diretamente acessíveis a partir da Internet (art. 32.º do Regulamento 756/2026). Para uma PME em Cegid Primavera e Microsoft 365, inclui: portais e acessos remotos ao ERP, servidores publicados (locais e cloud), VPN, domínios e integrações expostas a terceiros.

Além dos três prazos legais, o CNCS avalia a substância das políticas e a evidência de MFA ativo. MFA é o controlo com verificação mais direta: um login de teste confirma imediatamente se está implementado ou apenas declarado. É também o que elimina de forma mais eficaz a classe de incidentes mais frequente — credenciais comprometidas via phishing (documentámos um caso real, connosco como alvo) ou reutilização de palavras-passe.

Microsoft Defender + Sentinel — alinhamento prático

Muitas PME até 300 colaboradores (o limite dos planos Microsoft 365 Business) já têm Microsoft 365 Business Premium ou equivalente. Esse licenciamento inclui ferramentas que cobrem diretamente cinco dos dez controlos NIS2 — o problema quase nunca é a licença, é a configuração e a documentação que falta. Este é o mapeamento prático por ferramenta:

Microsoft Defender for Business (incluído no Microsoft 365 Business Premium)

Endereça os controlos #2 (deteção de incidentes), #5 (gestão de vulnerabilidades e patches) e #9 (segurança de ativos e endpoints). O que dá à PME em concreto: deteção e resposta em endpoint (EDR), avaliação de vulnerabilidades por dispositivo com recomendações de remediação, antivírus gerido centralmente a partir de uma única consola, e alertas de comportamento anómalo.

Para NIS2, o mais relevante é que o Defender for Business produz evidência auditável nativa: relatórios de vulnerabilidades com datas, histórico de alertas e ações de remediação, inventário de dispositivos geridos. É exatamente o que o CNCS pedirá numa verificação de eficácia das medidas (controlo #6). A licença existe — falta ativar as políticas de EDR em todos os endpoints, configurar as regras de redução de superfície de ataque, e resolver as vulnerabilidades críticas que aparecem no dashboard de segurança. Ter a licença sem configuração não cumpre o requisito.

Microsoft Entra ID P1 (incluído no Microsoft 365 Business Premium)

Endereça o controlo #10 (MFA e controlo de acessos) e o #9 (gestão de identidades e acessos). O Entra ID P1 permite Conditional Access — enforçar MFA de forma técnica e centralizada, não apenas como recomendação. Isso é a diferença operacional entre "temos MFA disponível" e "ninguém consegue entrar nos sistemas críticos sem MFA" — para o CNCS, só o segundo conta como controlo implementado.

A configuração mínima para NIS2 no Entra ID: política de Conditional Access que exige MFA para todos os utilizadores em todas as aplicações cloud da empresa; bloqueio de acessos de localizações de risco elevado (países sem relação com a operação); revisão trimestral dos utilizadores com privilégios de administrador. Com o Entra ID P1 — incluído no Microsoft 365 Business Premium — tudo isto é configurável sem ferramentas adicionais. Email, Teams, SharePoint e aplicações em nuvem ficam cobertos num único ponto de controlo.

Microsoft Sentinel (Azure — add-on separado)

O Sentinel é um SIEM cloud que agrega logs de múltiplas fontes — Azure, Microsoft 365, firewalls, aplicações de terceiros — e correlaciona eventos para deteção de ameaças avançadas que o Defender não deteta isoladamente. Para NIS2, endereça o controlo #2 (gestão de incidentes e deteção) e o #6 (avaliação de eficácia), com trilhos de auditoria completos e capacidade de gerar os relatórios de incidente estruturados que o CNCS exige.

Para a maioria das PMEs, o Sentinel é um passo de maturidade, não de arranque. Uma PME a começar o programa NIS2 deve primeiro configurar o Defender for Business e o Entra ID — e considerar o Sentinel quando a operação de segurança estiver estabilizada, tipicamente no segundo ano do programa. Para quem corre infraestrutura em Azure, a integração com o Sentinel é nativa e o custo de ingestão de logs da infra Azure e do Microsoft 365 é o mais direto de controlar. Se o ambiente é maioritariamente Microsoft 365 sem Azure significativo, o Defender cobre o essencial para o arranque sem o Sentinel.

Microsoft Intune (incluído no Microsoft 365 Business Premium)

Endereça o controlo #8 (criptografia) e o #9 (gestão de ativos e dispositivos). O Intune permite enforçar políticas de conformidade por dispositivo — encriptação de disco obrigatória (BitLocker em Windows, FileVault em Mac), versão mínima de sistema operativo, PIN de ecrã em dispositivos móveis — e integra com o Entra ID para bloquear acessos de dispositivos não conformes. É a base técnica para o inventário de ativos que o regulamento exige e para a política de criptografia de endpoints.

Documentação obrigatória vs opcional

A distinção é direta: o que é obrigatório por lei, com prazo ou consequência direta de coima; e o que é opcional mas reduz o risco de coima por negligência, de incidente grave, ou de uma inspecção que se alarga para além do âmbito inicial.

Documentação obrigatória

• Autoidentificação MyCiber — com dados da entidade, setores de atividade e contacto do responsável. Prazo (a contar da disponibilização da plataforma, 23-jun-2026): 60 dias úteis para entidades já em atividade (até 15-set-2026) / 30 dias a contar do início de atividade para as que a iniciem depois (RJC art.8.º).
• Política de segurança — documento formal, aprovado pela gestão, cobrindo os 10 controlos (art.27.º e 29.º). Revisão periódica documentada (a cadência anual é a referência de boa prática, ligada ao controlo #6 de avaliação da eficácia).
• Lista de ativos — ativos diretamente acessíveis a partir da Internet, com base no inventário (art. 32.º do Regulamento). Prazo: 31 de janeiro do ano seguinte à qualificação ou 6 meses.
• Responsável de segurança nomeado e comunicado ao CNCS — com dados de contacto e âmbito de responsabilidade. Prazo: 20 dias úteis após qualificação.
• Plano de resposta a incidentes — incluindo a cadeia de notificação ao CNCS (notificação inicial ≤24h, atualização até 72h quando necessária, fim do impacto ≤24h, relatório final em 30 dias úteis). Com designação explícita de quem notifica, como, e com que informação mínima.
• Avaliação de risco anual — documentada, com âmbito, metodologia, resultados e plano de remediação das lacunas identificadas.

Documentação opcional (mas relevante)

• Certificação ISO 27001 — não exigida por regra (o CNCS pode exigi-la, art. 30.º, n.º 5, do Regulamento 756/2026), mas, com âmbito integral, dá presunção de cumprimento das medidas (art. 27.º do Regulamento) e simplifica a demonstração de conformidade a clientes e parceiros. Para PMEs, o retorno começa a fazer sentido tipicamente no segundo ou terceiro ano após implementação do programa NIS2.
• Teste de intrusão (pentest) formal — não exigido nos níveis básico e substancial; no nível elevado, o Regulamento 756/2026 exige testes de intrusão regulares (controlo ID.AR-1). Cobre parcialmente o controlo #6 (avaliação de eficácia das medidas) e produz evidência objetiva sobre o estado real da segurança.
• SOC externo — válido para cobrir o controlo #2 (deteção de incidentes) em PMEs sem equipa de segurança interna. O contrato com o fornecedor SOC tem de cobrir explicitamente o tempo de resposta e o processo de notificação ao CNCS nos prazos legais.
• Alinhamento ao NIST CSF 2.0 ou ISO 27002 — referências internacionais, não exigidas pelo CNCS, mas úteis como estrutura interna para o plano de remediação e para comunicação com parceiros internacionais.

Em inspeções, o CNCS verifica a existência e substância dos documentos obrigatórios — não o número de certificações. Uma política de segurança bem escrita, aprovada pela gestão e com evidência de revisão anual, vale mais do que um processo de certificação ISO 27001 a meio e sem política formal aprovada. O básico real é mais valioso que o avançado incompleto.

Janela realista para ficar conforme

Uma PME que inicie hoje o programa NIS2 de raiz precisa de 5 a 6 meses para ter os documentos obrigatórios em ordem e os controlos técnicos críticos implementados. O calendário realista, fase a fase:

1. Semanas 1–2: Qualificação e arranque formal. Confirmar o âmbito (entidade essencial ou importante), identificar os setores de atividade abrangidos, nomear o responsável de segurança e iniciar o registo MyCiber. Estas duas primeiras semanas determinam os prazos legais das fases seguintes — não podem ser adiadas.
2. Semanas 2–6: Inventário e gap analysis. Inventário de ativos (redes, sistemas, aplicações, dados críticos, fornecedores de TI), gap analysis contra os 10 controlos (art.27.º e 29.º), e priorização por risco. A ferramenta de inventário pode ser tão simples como uma folha de cálculo estruturada — o que importa é estar completo, datado e com responsável atribuído.
3. Semanas 4–10: Controlos técnicos críticos. MFA via Conditional Access (Entra ID P1), ativação e configuração do Defender for Business em todos os endpoints, política de backups testada com RTO/RPO documentados, e encriptação de disco via Intune. Para PMEs com Microsoft 365 Business Premium, estes controlos são implementáveis sem aquisição de licenças adicionais — o que falta é a configuração correta e os testes documentados.
4. Semanas 8–16: Documentação obrigatória. Política de segurança, plano de resposta a incidentes com cadeia de notificação ao CNCS, política de acessos e offboarding, política de criptografia e gestão de patches. Estes documentos podem ser desenvolvidos internamente — não precisam de ser extensos, precisam de ser específicos à empresa e com aprovação da gestão datada.
5. Semanas 14–20: Cadeia de fornecedores e formação. Avaliação de risco dos fornecedores críticos de TI, atualização de contratos com cláusulas de segurança mínimas, e sessão de formação para toda a equipa com registo de presença. A formação anual documentada é um dos controlos com verificação mais simples em inspeção.
6. Semanas 20–24: Avaliação de eficácia e ciclo anual. Primeira autoavaliação interna das medidas implementadas, documento de resultados e plano de remediação para o ano seguinte. Esta é a base do ciclo anual de conformidade que o regulamento exige.

Para PMEs que já têm Microsoft 365 Business Premium ativo — mesmo que mal configurado — o tempo reduz 6 a 8 semanas: o Defender, o Entra ID P1 e o Intune já estão disponíveis na licença. O que tipicamente não está feito: as políticas de Conditional Access enforçadas para todos os utilizadores (não apenas ativadas), o Defender a funcionar em modo EDR nos endpoints com vulnerabilidades críticas resolvidas, e os backups com RPO e RTO testados e registados.

Continuidade operacional além do ataque: as lições do apagão de 2025

A 28 de abril de 2025, Portugal continental e Espanha sofreram um apagão total; a reposição da rede de transporte só terminou às 00h22 de 29 de abril em Portugal e às 4h00 em Espanha. Entre as 84 subscrições Azure que temos sob gestão, nenhuma perdeu operação. A diferença entre quem parou e quem não parou não foi o azar — foram decisões técnicas tomadas 12 a 24 meses antes. E são as mesmas que protegem contra os cenários muito mais frequentes: ransomware, falha do ISP, disco do servidor que morre, incêndio no escritório. Por ordem de impacto:

1. Sistemas de gestão em cloud, não em servidor local. ERP, e-mail e ficheiros em Azure ou SaaS equivalente — o servidor no escritório é um ponto único de falha, e também o alvo preferido do ransomware.
2. Backup fora da zona de impacto. Replicação geo-redundante (West Europe → North Europe); um backup local na mesma rede é encriptado pelo mesmo ataque que encripta a produção.
3. UPS nos pontos críticos. Switches e postos essenciais aguentam 1–4 horas; gerador só quando frio, saúde ou produção contínua o justificam.
4. Conectividade redundante. Fibra principal + fallback 4G/5G automático — os portáteis e os POS continuam a trabalhar quando o ISP cai.
5. Monitorização com alertas ativos. Defender e Azure Monitor a avisar a equipa antes do primeiro telefonema interno.
6. Plano de comunicação em falha. Quando o e-mail não funciona: quem fala com quem, por onde, e quem atualiza os clientes a cada hora.
7. Teste anual. Desligar o ISP principal numa manhã qualquer e ver o que falha — é assim que se descobre o UPS com as baterias mortas.

O que é continuidade operacional

Continuidade operacional é a capacidade de manter os processos críticos (faturar, atender, pagar, produzir) a funcionar, ou de os recuperar em minutos e horas, não em dias, quando um sistema, um fornecedor de energia ou de internet, ou um ataque os interrompe. Define-se com duas métricas por sistema: o RTO (quanto tempo até voltar a trabalhar) e o RPO (quantos dados se perdem entre o último backup válido e a falha). O ERP e o e-mail toleram minutos a poucas horas; um relatório interno de BI tolera um dia. Tratar tudo com o mesmo nível custa mais e protege pior.

O custo real de uma hora parada

O custo de uma paragem não é uma taxa fixa. É a soma de quatro parcelas que se acumulam enquanto dura:

• Mão de obra bloqueada. Colaboradores sem sistemas multiplicados pelo custo-hora carregado. Exemplo de cálculo: 40 pessoas a 18 euros por hora carregada, uma manhã de 4 horas sem sistemas, são 2 880 euros só em pessoas paradas.
• Faturação atrasada. Sem ERP não se emite fatura, não se regista venda, não se confirma stock. Quase sempre é dinheiro atrasado, com parte em risco se o cliente encomendar a outro entretanto.
• Recuperação de emergência. Suporte reativo, sob pressão e fora de horas, custa mais do que a hora contratada em bolsa. É a fatura que chega semanas depois.
• Exposição contratual. Quem fornece clientes com SLA próprio (indústria, logística, serviços financeiros) arrisca penalização, não pela paragem, mas por não a conseguir justificar com um plano documentado.

Backup não é continuidade

Ter backup responde ao RPO. Não responde ao RTO, que é o que pára a operação: onde restaurar, com que infraestrutura, com que configuração do Cegid Primavera, com que integrações reativadas e quem fala com os clientes entretanto. Três formas como «já temos backup» falha: o backup está na mesma rede que a produção e o ransomware encripta os dois; o backup nunca foi restaurado desde que foi configurado; o backup existe, mas não há plano à volta dele. Dos quatro controlos que cobrem a maior parte do risco de uma PME (MFA, Defender, backup testado e plano de resposta), o backup testado é só um. A continuidade é o que liga os quatro a um RTO concreto por sistema.

Plano para uma PME sem equipa de IT

1. Inventariar os sistemas críticos e as dependências (ERP, e-mail, ficheiros, pagamentos, ligação a bancos): onde vive cada um, quem o gere, o que acontece se falhar quatro horas.
2. Definir RTO e RPO por sistema, não um número único para tudo.
3. Tirar a camada aplicacional do escritório. Cegid Primavera Evolution Cloud e Microsoft 365 removem a dependência de uma máquina física de uma só vez.
4. Suporte com SLA escrito, não «conforme disponibilidade». Sem tempo de resposta contratualizado, a recuperação depende de quem atender o telefone nesse dia.
5. Plano de comunicação simples: um grupo de mensagens já criado e um responsável designado para quando o e-mail não funciona.
6. Testar uma vez por ano, desligando a ligação principal numa manhã qualquer.

Como o stack Cegid + Microsoft sustenta a operação

O Cegid Primavera Evolution Cloud tira o ERP do servidor do escritório. O Microsoft 365 faz o mesmo ao e-mail e aos ficheiros, e o Entra ID garante que o acesso com MFA não depende de uma rede física. No Azure, a região por omissão é West Europe, com replicação para North Europe nos sistemas que o justificam: foi essa arquitetura que manteve em operação as subscrições Azure sob gestão da HeraPrime durante o apagão de 2025. A HeraPrime gere esta camada com o SLA de 3 horas contratualizado e a infraestrutura Azure configurada com RTO e RPO por sistema, não como um serviço genérico de cloud.

A fiscalização reforçada em 2026 não significa que o CNCS vai inspecionar todas as entidades em âmbito de imediato. Significa que o processo de qualificação está em curso, e que entidades que sofram incidentes ou sobre as quais haja denúncia ficam sujeitas a verificação com os prazos e coimas do regime. A janela para preparar antes de ser verificada existe — mas não é indefinida. A pergunta útil não é "quando vai a CNCS verificar?" — é "se verificassem na próxima semana, o que estaria em falta?". A resposta a essa pergunta, obtida num levantamento estruturado de 60 minutos, define a prioridade do próximo trimestre. Mais contexto regulatório na página dedicada ao NIS2 em Portugal — âmbito, obrigações e prazos.

---

Fontes consultadas: Decreto-Lei n.º 125/2025 (Regime Jurídico da Cibersegurança, transposição da Diretiva UE 2022/2555 — NIS2) · Regulamento n.º 756/2026 · Regulamento (UE) 2016/679 — RGPD · Documentação técnica Microsoft Defender for Business, Entra ID, Sentinel e Intune · Orientações publicadas pelo CNCS (Centro Nacional de Cibersegurança).