A transposição da NIS2 em Portugal já não é um projeto futuro. O Decreto-Lei n.º 125/2025, de 4 de dezembro, aprovou o novo regime jurídico da cibersegurança e entrou em vigor em 3 de abril de 2026. O Regulamento n.º 756/2026 desenvolve parte do regime. Para uma organização portuguesa, a pergunta útil já não é «quando haverá transposição?», mas «qual é a nossa classificação, que dever se aplica e quando começa o respetivo prazo?». A resposta exige ler a lei nacional, não apenas repetir os prazos da diretiva europeia.
Este guia separa quatro decisões: enquadramento da entidade, gestão do risco, comunicação de incidentes significativos e calendário de implementação. É um roteiro para responsáveis de segurança, direção e assessoria jurídica; a classificação definitiva depende das atividades e das normas aplicáveis à entidade concreta.
Pontos essenciais
- A NIS2 foi transposta pelo Decreto-Lei n.º 125/2025; o antigo atraso de transposição é contexto histórico, não o estado atual.
- O âmbito não se resolve com a pergunta «tem 50 trabalhadores?». Setor, dimensão, exceções, jurisdição e categoria da entidade devem ser analisados em conjunto.
- A lei portuguesa prevê um fluxo de incidente significativo que não equivale ao resumo genérico «24 horas, 72 horas, um mês» da diretiva.
- O artigo 10.º, n.º 2, adia apenas disposições identificadas e liga o respetivo prazo à publicação do regulamento indicado, não à entrada em vigor de todo o decreto.
- Um incidente de cibersegurança pode também envolver dados pessoais; a avaliação do RGPD e da CNPD é separada.
O que está efetivamente em vigor
A Diretiva (UE) 2022/2555 fixava aos Estados-Membros um prazo de transposição até outubro de 2024. Portugal ultrapassou-o, mas entretanto aprovou o Decreto-Lei n.º 125/2025. O diploma revê o enquadramento anterior da Lei n.º 46/2018 e estabelece as categorias, responsabilidades, gestão de risco e mecanismos de supervisão nacionais. Quem consulta apenas a diretiva, ou uma notícia do período de atraso, pode chegar hoje à conclusão errada de que a preparação ainda é voluntária.
O Regulamento n.º 756/2026, publicado em Diário da República entrou em vigor no dia seguinte à sua publicação de 22 de junho de 2026. Essa data não transforma automaticamente todos os deveres técnicos em deveres com o mesmo prazo. Os seus artigos 34.º e 35.º preservam a transição prevista no artigo 10.º, n.º 2, do decreto e remetem matérias dependentes de instruções técnicas para a publicação dessas instruções. Ao montar um calendário, anote em cada linha a disposição, o evento que inicia o prazo, a fonte publicada e a equipa responsável. Não use «junho de 2028» como data universal para qualquer obrigação.
Também é importante distinguir o CNCS, que exerce funções nacionais de cibersegurança, das entidades competentes para outros regimes. A análise de um prestador financeiro, por exemplo, pode ter de considerar a DORA, mas a coincidência de controlos não elimina as regras específicas de cada regime. A existência de dois referenciais não justifica duplicar inventários quando a mesma evidência factual serve ambos; justifica manter decisões e deveres separados.
Primeiro passo: classificar a entidade
Os artigos 3.º a 7.º do decreto exigem uma leitura do setor e das atividades, da dimensão, das exceções e da jurisdição. As categorias nacionais incluem entidades essenciais, importantes e entidades públicas relevantes. Não basta observar o código de atividade principal ou o número total de empregados. Um grupo pode prestar serviços diferentes por sociedades distintas; uma sociedade pode ter atividades no âmbito e fora dele. Algumas categorias têm regras especiais de inclusão independentemente do teste geral de dimensão.
Faça uma ficha de enquadramento por pessoa coletiva. Registe serviços prestados, setor dos anexos, local de estabelecimento, clientes ou funções relevantes, indicadores de dimensão e motivo da classificação proposta. Recolha a interpretação jurídica de cada exceção antes de marcar «fora do âmbito». Se uma pequena organização presta um serviço especialmente abrangido, a etiqueta PME não é uma exclusão automática. Se uma grande empresa vende apenas um serviço que não pertence aos setores abrangidos, o tamanho por si só não cria uma categoria NIS2.
A classificação tem consequências práticas. As entidades essenciais e importantes não são uma simples escala de maturidade tecnológica; a categoria influencia deveres e poderes de supervisão. Por isso, a administração deve aprovar a conclusão de âmbito e rever a ficha quando há aquisição de atividade, mudança de serviço ou reorganização societária. Uma tabela genérica de «médias = importantes, grandes = essenciais» é apenas uma hipótese inicial e falha nos casos especiais da lei.
Exemplo hipotético: um operador de serviços digitais tem 35 trabalhadores e uma subsidiária que presta outro serviço a entidades públicas. Não se deve concluir que ambas ficam excluídas porque cada equipa é pequena, nem classificar o grupo inteiro por uma única atividade. O jurídico mapeia cada entidade e a função efetiva; a segurança identifica os sistemas que suportam o serviço eventualmente abrangido. A decisão documentada pode ser corrigida perante novas informações sem reconstruir todo o inventário.
Gestão de risco: transformar a norma em evidência
O regime português transpõe a lógica de medidas técnicas, operacionais e organizativas proporcionais ao risco. Para uma entidade abrangida, o ponto de partida é identificar serviços essenciais para a sua atividade, dependências de sistemas, fornecedores e consequências da indisponibilidade. Depois, atribua donos a medidas verificáveis: análise de risco, resposta a incidentes, continuidade, cópias de segurança, segurança na aquisição e manutenção, cadeia de fornecimento, formação, controlo de acesso e avaliação de eficácia. Ter uma política aprovada sem execução documentada não resolve o risco.
Um inventário útil liga cada sistema a um serviço, ao responsável interno, ao fornecedor que o opera, aos dados ou processos críticos e ao plano de recuperação. Uma falha num sistema de agendamento pode ter impacto diferente da mesma falha num sistema que mantém serviço clínico em funcionamento. A decisão sobre testes de cópias de segurança, redundância e prioridade de restauro deve refletir essa diferença. Esta é uma recomendação operacional baseada no risco; não é uma lista de produtos obrigatórios definida pelo decreto.
O órgão de gestão precisa de informação que permita aprovar e acompanhar as medidas. Em vez de uma apresentação anual sem números verificáveis, peça uma síntese periódica: sistemas críticos sem dono, testes de recuperação falhados, incidentes e ações ainda abertas, fornecedores de alto impacto sem avaliação. O objetivo não é transferir o trabalho técnico para administradores, mas permitir que estes supervisionem a adequação de recursos e decisões. Guarde as atas e a versão das políticas aprovadas.
Para fornecedores TIC, anote o que o fornecedor pode fazer, que acesso tem, que evidência de segurança entrega, quem notifica um incidente e como ocorre a saída. A revisão não termina na assinatura inicial. Mudança de infraestrutura, subcontratação ou falha repetida podem alterar a avaliação. No setor financeiro, compare esse inventário com a diligência de terceiros TIC prevista na DORA e com o registo de informação DORA, sem presumir que um único formulário satisfaz dois regimes.
Incidentes significativos: o relógio português
Os artigos 40.º a 44.º do decreto tratam dos incidentes significativos das entidades abrangidas. A equipa de resposta deve guardar a hora da deteção, a hora em que concluiu que há ou pode haver um incidente significativo e a fundamentação. Não confunda essa determinação com a primeira suspeita técnica. O artigo 42.º pede notificação inicial à autoridade de cibersegurança competente sem demora injustificada e até 24 horas depois dessa verificação, salvo quando isso seja incompatível com a mitigação ou resolução do incidente. É uma exceção delimitada; não autoriza adiar por conveniência administrativa.
A comunicação inicial contém, entre outros elementos previstos na lei, identificação de contacto, indicação temporal e descrição breve da causa e dos efeitos, sempre que possível. Se ainda não há causa confirmada, declare a incerteza e mantenha o registo dos factos conhecidos. O artigo 42.º prevê uma atualização, quando necessária, até 72 horas após a verificação do incidente significativo; isto não deve ser apresentado como uma segunda notificação universal e indiferenciada. O artigo 41.º, n.º 2, contém ainda uma via especial: se o incidente for resolvido até duas horas depois da deteção, basta a notificação do fim de impacto significativo. Na triagem, inclua essa hipótese, mas não a use sem verificar os seus pressupostos.
Quando o incidente perde o impacto significativo, o artigo 43.º exige uma comunicação sem demora injustificada e até 24 horas depois, com atualização e descrição da situação. O artigo 44.º conta então 30 dias úteis a partir da notificação do fim do impacto significativo para o relatório final. Se o incidente continua, a autoridade pode pedir relatórios intercalares semanais. Estes marcos são diferentes de «relatório final um mês após a primeira notificação». Um quadro de gestão deve manter separadas as horas de deteção, determinação, notificações, perda do impacto e pedido da autoridade.
Exemplo hipotético: na segunda-feira, às 09:00, uma equipa encontra indisponibilidade parcial, mas ainda não sabe se afeta um serviço abrangido. Às 14:00 conclui, com factos documentados, que o incidente pode ser significativo. Esse é o marco relevante para calcular a comunicação inicial do artigo 42.º, sem prejuízo do dever de agir sem demora injustificada. Na quarta-feira, a equipa atualiza informação quando necessário. Quando o impacto significativo cessa, regista nova hora, comunica o fim e calcula o prazo de 30 dias úteis para o relatório final a partir dessa comunicação. Não se substitui este exercício por um temporizador genérico de 24/72 horas.
NIS2 e RGPD: dois testes, por vezes duas comunicações
Uma avaria de rede que não expôs dados pessoais pode ser um incidente de cibersegurança, mas não necessariamente uma violação de dados pessoais. Um envio indevido de ficheiro médico pode ser uma violação de dados mesmo sem interromper serviço essencial. Um ransomware pode satisfazer ambos os testes. A equipa deve abrir avaliações paralelas: significância e âmbito sob o decreto de cibersegurança; violação de segurança de dados, risco para pessoas e comunicação sob o RGPD.
O artigo 33.º do RGPD exige notificação à autoridade de proteção de dados sem demora injustificada e, quando viável, até 72 horas depois de o responsável ter conhecimento da violação, exceto se for improvável que resulte risco para direitos e liberdades. Se notificar mais tarde, explique o atraso. Toda violação de dados pessoais deve ser documentada; a comunicação aos titulares do artigo 34.º depende de risco elevado e respetivas exceções. O guia sobre notificação de violação de dados à CNPD desenvolve esse segundo percurso. Um registo técnico único pode conter evidência comum, mas decisões, destinatários e prazos não devem ser fundidos.
Também há sobreposição entre inventário de ativos de cibersegurança e registo de atividades de tratamento RGPD. O primeiro descreve dependências e continuidade de serviços; o segundo descreve finalidades, categorias de titulares, destinatários e restantes elementos do artigo 30.º. Relacione os registos por identificador de aplicação ou fornecedor, sem afirmar que um substitui o outro.
Como organizar os próximos passos
Comece por uma decisão de âmbito assinada, depois um mapa dos serviços e sistemas que a suportam. Para cada serviço potencialmente abrangido, documente risco, medidas existentes, lacunas e pessoa que aceita ou trata o risco. Em seguida, ensaie uma ocorrência: quem determina significância, quem valida conteúdo, quem envia à autoridade e como se atualiza a informação se o responsável habitual estiver ausente. O exercício costuma revelar problemas mais concretos do que uma longa lista de controlos: contactos desatualizados, contratos sem dever de alerta ou logs que não permitem reconstruir a hora de determinação.
Construa um calendário de transição por artigo, não um plano com uma só data. O artigo 10.º, n.º 2, difere a aplicação dos artigos 27.º, n.os 1 e 2, 28.º a 30.º, 33.º e 61.º, n.º 1, alíneas b), c) e f), por 24 meses após a publicação do regulamento referido. Confirme as disposições exatas e eventuais instruções técnicas antes de marcar uma tarefa como vencida. As restantes obrigações não recebem automaticamente essa dilação. Documente a fonte jurídica consultada e a data de revisão; o calendário é uma ferramenta de governação, não uma conclusão universal sobre qualquer organização.
Na compra de ferramentas, peça demonstrações de registo de incidentes com múltiplos marcos temporais, controlo de versões das notificações, tarefas atribuídas e exportação da evidência. Uma solução anunciada como software NIS2 em Portugal só é útil se suportar o processo que a sua entidade realmente tem. O software de conformidade RGPD pode apoiar o fluxo de dados pessoais, mas não prova por si a classificação nacional NIS2. Quando houver exigências financeiras, avalie separadamente o software DORA. Pergunte aos fornecedores pelo fluxo concreto, limitações e custos contratuais atuais em vez de comprar com base num rótulo «conforme».
Perguntas frequentes
A NIS2 já foi transposta em Portugal?
Sim. O Decreto-Lei n.º 125/2025 transpôs a diretiva e entrou em vigor em 3 de abril de 2026. O Regulamento n.º 756/2026 desenvolve parte da execução, com regras próprias de entrada em vigor e remissões para instruções técnicas. Um dever específico pode ter transição; isso não torna a transposição pendente.
Uma empresa pequena está sempre fora do âmbito?
Não. A dimensão é um elemento do teste, mas setor, atividade, exceções, jurisdição e categorias especiais podem alterar o resultado. Registe uma análise por entidade e serviço; não substitua a lei por uma regra genérica de número de trabalhadores.
O relatório final vence um mês após o alerta?
Não como regra portuguesa geral. Para o fluxo dos artigos 40.º a 44.º, o artigo 44.º fixa 30 dias úteis contados da notificação do fim do impacto significativo. Se o incidente continua, podem ser pedidos relatórios intercalares semanais. O artigo 41.º, n.º 2, ainda prevê apenas a comunicação do fim do impacto quando há resolução até duas horas após a deteção.
A plataforma de software envia as comunicações por nós?
Uma ferramenta pode preparar informação e trilho de decisão, mas confirme a funcionalidade contratada e o canal legal aplicável antes de confiar nela. A responsabilidade pelo conteúdo e pelo prazo continua com a entidade obrigada. Não confunda um formulário interno, a plataforma estatutária e a comunicação separada à CNPD.
Conclusão
Em setembro de 2026, a decisão relevante é aplicar o regime português em vigor ao serviço concreto. Classifique a entidade, traduza os riscos em controlos demonstráveis e ensaie o processo de incidente com os marcos nacionais corretos. Trate as transições artigo por artigo e mantenha separado o teste do RGPD. Assim, o programa deixa de depender de uma notícia antiga sobre transposição e passa a produzir decisões que a direção e a autoridade podem verificar.