(Atualizado em 23 de agosto de 2026.)
O Regulamento de Execução (UE) 2024/2690 da Comissão, de 17 de outubro de 2024, estabelece requisitos técnicos e metodológicos para a aplicação das medidas de gestão dos riscos de cibersegurança previstas na Diretiva NIS2 e concretiza os critérios segundo os quais determinados incidentes devem ser considerados significativos.
O regulamento foi publicado no Jornal Oficial da União Europeia em 18 de outubro de 2024 e entrou em vigor em 7 de novembro de 2024, no vigésimo dia seguinte ao da sua publicação. É obrigatório em todos os seus elementos e diretamente aplicável em todos os Estados-Membros.
Não foi previsto um período transitório adicional. O regulamento tornou-se aplicável com a sua entrada em vigor.
O regulamento foi adotado ao abrigo do artigo 21.º, n.º 5, primeiro parágrafo, e do artigo 23.º, n.º 11, segundo parágrafo, da Diretiva (UE) 2022/2555.
O diploma não substitui a NIS2, não transpõe a diretiva e não determina, isoladamente, que uma entidade fica abrangida pelo regime. A qualificação como entidade essencial ou importante continua a depender da NIS2 e da legislação nacional aplicável. Uma vez abrangida e pertencendo a uma das categorias expressamente enumeradas, a entidade deve cumprir também os requisitos pormenorizados do regulamento.
O regulamento concretiza duas matérias diferentes:
Os critérios do regulamento determinam a relevância do incidente, mas não substituem o procedimento, os destinatários, o conteúdo nem os prazos de notificação estabelecidos pela NIS2 e pelo direito nacional.
O regulamento aplica-se, dentro do âmbito da NIS2, às seguintes entidades:
A enumeração é específica. Por exemplo, as entidades que prestam serviços de registo de nomes de domínio, os fornecedores de pontos de troca de tráfego e os fornecedores de redes públicas de comunicações eletrónicas podem estar sujeitos à NIS2, mas não ficam abrangidos por este regulamento apenas por exercerem essas atividades. O mesmo se aplica a qualquer entidade de outro setor que não preste também um dos serviços expressamente enumerados.
As medidas devem assegurar um nível de segurança adequado aos riscos. Na sua aplicação devem ser considerados o grau de exposição, a dimensão e a estrutura da entidade, a probabilidade e a gravidade dos incidentes e o respetivo impacto societal e económico.
Quando a dimensão da entidade impeça a aplicação de determinado requisito técnico ou metodológico, podem ser adotadas medidas compensatórias adequadas que permitam alcançar o mesmo objetivo. O considerando 5 apresenta, para as microentidades, o exemplo da supervisão específica pela direção ou do reforço da monitorização e do registo quando não seja possível separar funções incompatíveis.
Esta possibilidade não equivale a uma dispensa geral. Sempre que o anexo utilize expressões como «se for caso disso», «quando aplicável» ou «na medida do possível» e a entidade conclua que um requisito não é adequado, aplicável ou viável, deve documentar de forma compreensível a respetiva fundamentação.
O anexo organiza as medidas de gestão dos riscos de cibersegurança em treze grupos:
A política de segurança dos sistemas de rede e informação deve constituir o documento de mais alto nível da abordagem de segurança da entidade. Deve estar alinhada com a estratégia e os objetivos da organização, definir objetivos, recursos, funções e responsabilidades, identificar as políticas temáticas e a documentação a conservar e estabelecer indicadores que permitam acompanhar a sua aplicação e o nível de maturidade.
A política deve ser formalmente aprovada pelo órgão de direção e analisada, e se necessário atualizada, pelo menos anualmente e sempre que ocorra um incidente significativo ou uma alteração significativa das operações ou dos riscos. O resultado da análise deve ser documentado.
As responsabilidades e autoridades em matéria de segurança devem ser atribuídas e comunicadas. Pelo menos uma pessoa deve responder diretamente perante o órgão de direção pelas questões de segurança dos sistemas de rede e informação. Quando aplicável, deve existir separação entre funções e áreas de responsabilidade incompatíveis.
A entidade deve manter um quadro de gestão dos riscos integrado, quando aplicável, na sua gestão global do risco. As avaliações dos riscos devem ser realizadas e documentadas e conduzir a um plano de tratamento dos riscos que identifique prioridades, medidas, responsáveis e prazos. Os riscos residuais devem ser formalmente aceites pelo órgão de direção ou pelas pessoas com autoridade para os gerir, assegurando-se a devida comunicação ao órgão de direção.
O cumprimento e a eficácia das políticas e medidas devem ser objeto de acompanhamento, medição e análises independentes realizadas a intervalos planeados e sempre que ocorram incidentes significativos ou alterações significativas das operações ou dos riscos.
A entidade deve dispor de uma política de tratamento de incidentes, articulada com a continuidade das atividades e a recuperação de desastres, que defina:
Devem existir procedimentos e ferramentas de monitorização e registo capazes de detetar eventos suscetíveis de constituir incidentes. Na medida do possível, a monitorização deve ser automatizada e contínua ou efetuada a intervalos regulares. Os registos, e as respetivas cópias de segurança, devem ser conservados por um período predefinido e protegidos contra acessos ou alterações não autorizados.
O âmbito de registo pode incluir tráfego de rede, gestão de utilizadores e autorizações, acessos, autenticação, contas privilegiadas, alterações de configuração, ferramentas de segurança, utilização de recursos, acessos físicos e eventos ambientais. Na medida do possível, os sistemas devem usar fontes horárias sincronizadas e a disponibilidade dos sistemas de monitorização e registo deve ser acompanhada separadamente dos sistemas monitorizados.
A entidade deve criar um mecanismo simples para trabalhadores, fornecedores e clientes comunicarem eventos suspeitos. Deve avaliar e classificar esses eventos, correlacionar registos e reavaliar a classificação sempre que surjam novas informações.
A existência de incidentes recorrentes deve ser avaliada trimestralmente. A resposta documentada deve abranger contenção, erradicação e recuperação, bem como preservação dos elementos de prova. Os procedimentos devem ser testados a intervalos planeados e, quando adequado, seguidos de uma análise pós-incidente que identifique a causa primária e os ensinamentos retirados.
A entidade deve estabelecer e manter um plano de continuidade das atividades e de recuperação de desastres baseado na avaliação dos riscos. O plano deve definir, quando aplicável, o âmbito, as responsabilidades, os contactos, as condições de ativação e desativação, a ordem de recuperação, os objetivos de recuperação, os recursos necessários e a transição para o restabelecimento normal das operações.
Deve ainda ser realizada uma análise de impacto na atividade e estabelecidos requisitos de continuidade. O regulamento incentiva a definição, quando adequada, dos períodos máximos toleráveis de interrupção, dos objetivos de tempo de recuperação, dos objetivos de ponto de recuperação e dos objetivos de prestação de serviços.
As cópias de segurança devem ser completas e exatas, incluindo dados de configuração e dados armazenados em ambientes de computação em nuvem. Devem ser armazenadas em locais seguros fora da rede do sistema e suficientemente afastados das instalações principais, estar sujeitas a controlos de acesso e a períodos de conservação definidos e ser objeto de verificações de integridade e de testes regulares de recuperação.
A redundância deve abranger, pelo menos parcialmente e de acordo com o risco, sistemas, instalações, equipamentos, fornecimentos, pessoal e canais de comunicação. Deve igualmente existir um processo de gestão de crises, com responsabilidades, comunicação com as autoridades e medidas destinadas a manter a segurança durante a crise.
A política de segurança da cadeia de abastecimento deve abranger as relações com fornecedores e prestadores de serviços diretos. A seleção e contratação deve considerar as práticas de cibersegurança, o desenvolvimento seguro, a capacidade para cumprir os requisitos definidos, a qualidade e resiliência dos produtos e serviços e, quando aplicável, a diversificação e a redução da dependência de um fornecedor.
Com base no risco, os contratos e acordos de nível de serviço devem prever, quando aplicável:
A entidade deve manter atualizado um diretório dos fornecedores e prestadores de serviços diretos, com os respetivos pontos de contacto e a lista dos produtos, serviços e processos de TIC fornecidos.
Os requisitos de segurança devem acompanhar todo o ciclo de vida dos produtos, serviços e sistemas de TIC. A entidade deve definir requisitos de segurança na aquisição, obter informações sobre componentes e funções de segurança, validar o cumprimento e assegurar atualizações durante a vida útil ou a substituição no final do suporte.
O desenvolvimento interno ou externalizado deve seguir regras de desenvolvimento seguro em todas as fases, incluindo requisitos de segurança, princípios de codificação segura, cibersegurança desde a conceção, arquiteturas de confiança zero, proteção dos ambientes de desenvolvimento e testes de segurança.
Devem existir processos documentados de gestão da configuração, alterações, reparações e manutenção. As alterações devem ser testadas e avaliadas antes da aplicação; as alterações de emergência que não possam seguir o processo normal devem ser documentadas e justificadas.
A política de testes de segurança deve definir, com base no risco, a necessidade, o âmbito, a frequência e o tipo de testes. Estes podem incluir testes manuais ou automatizados, testes de penetração, análise de vulnerabilidades, testes estáticos e dinâmicos de aplicações, testes de configuração e auditorias. As constatações críticas devem dar origem a medidas de atenuação.
As correções de segurança devem ser obtidas de fontes fiáveis, ter a integridade verificada, ser testadas e aplicadas num prazo razoável. A decisão de não aplicar uma correção quando as desvantagens superem os benefícios de cibersegurança deve ser devidamente documentada e fundamentada, com medidas adicionais e aceitação do risco residual.
A segurança da rede inclui documentação atualizada da arquitetura, restrição de acessos e comunicações desnecessários, proteção do acesso remoto, autorização temporária do acesso de prestadores, segmentação de redes, separação entre produção, desenvolvimento, testes e administração, proteção contra software malicioso e tratamento de vulnerabilidades.
O regulamento exige ainda planos para a transição segura e gradual para protocolos de comunicação de camadas de rede de última geração e para a implantação de normas modernas e interoperáveis de segurança do correio eletrónico, bem como a aplicação das melhores práticas de segurança do DNS, do encaminhamento da Internet e da higiene do encaminhamento.
Os trabalhadores, membros dos órgãos de direção e, quando aplicável, fornecedores diretos devem conhecer as suas responsabilidades e receber sensibilização e formação adequadas às funções e aos riscos. A alocação de pessoal e de recursos humanos às funções de segurança deve ser analisada a intervalos planeados e, pelo menos, uma vez por ano.
Devem ser definidos critérios proporcionados de verificação de antecedentes para funções relevantes, respeitando a legislação aplicável, bem como deveres que permaneçam após a cessação ou alteração do vínculo laboral, procedimentos de devolução ou supressão de ativos e um processo disciplinar para violações das políticas de segurança.
O controlo do acesso lógico e físico deve assentar nos princípios da necessidade de tomar conhecimento, do menor privilégio e da separação de funções. Devem ser geridos os ciclos de vida das identidades e dos direitos de acesso, restringidas as contas partilhadas, usadas contas administrativas específicas e protegidos os sistemas de administração.
A autenticação deve ser adequada à classificação dos ativos. Quando apropriado, os utilizadores devem ser autenticados através de vários fatores ou de mecanismos de autenticação contínua. Para contas privilegiadas e administrativas são exigidos procedimentos fortes de identificação, autenticação e autorização.
A entidade deve manter políticas de criptografia e gestão de chaves, classificar os ativos e conservar um inventário exaustivo, exato, atualizado e coerente. A política de suportes amovíveis deve limitar a sua utilização, desativar a execução automática e prever deteção de código malicioso e proteção dos dados.
A segurança física e ambiental deve abranger serviços de utilidade pública, energia, telecomunicações, temperatura, humidade, água e outras dependências, ameaças naturais ou intencionais, perímetros de segurança, controlos de entrada e monitorização contínua do acesso físico não autorizado.
Nos termos do artigo 3.º, um incidente é considerado significativo quando satisfaça pelo menos um dos seguintes critérios:
Para calcular as perdas financeiras diretas devem ser considerados, entre outros, os custos de substituição ou relocalização de equipamentos, software ou infraestruturas, custos extraordinários de pessoal, incumprimento contratual, reparação e indemnização de clientes, perda de receitas, comunicação, aconselhamento jurídico, perícia forense e serviços de resposta. Não são incluídas coimas, custos correntes de funcionamento nem investimentos destinados a melhorar a atividade após o incidente.
As interrupções programadas e as consequências previstas de operações de manutenção programadas não são consideradas incidentes significativos.
Incidentes que, isoladamente, não sejam significativos devem ser considerados coletivamente como um incidente significativo quando se verifiquem cumulativamente três condições:
O incidente é significativo quando:
O último critério não se aplica quando, por má configuração, estejam incorretos os dados de menos de 1 000 nomes de domínio e estes não representem mais de 1% dos nomes de domínio geridos pelo prestador.
O incidente é significativo quando um serviço de resolução com autoridade fica completamente indisponível, quando durante mais de uma hora o tempo médio de resposta aos pedidos de DNS é superior a 10 segundos ou quando fica comprometida a integridade, confidencialidade ou autenticidade dos dados tratados no âmbito da operação técnica do TLD.
Ao contrário do critério aplicável aos prestadores de DNS, a indisponibilidade total do serviço de resolução com autoridade de um registo de TLD não está sujeita, no artigo 6.º, a uma duração mínima expressa.
O incidente é significativo quando:
O incidente é significativo quando um serviço de um centro de dados operado pelo prestador fica completamente indisponível, quando a disponibilidade fica limitada durante mais de uma hora, quando a integridade, confidencialidade ou autenticidade dos dados fica comprometida em resultado de uma ação presumivelmente maliciosa ou quando o acesso físico ao centro de dados fica comprometido.
A indisponibilidade total de um serviço de centro de dados não está sujeita, no artigo 8.º, a uma duração mínima expressa.
Para CDN, MSP e MSSP, os critérios seguem a mesma estrutura essencial da computação em nuvem:
Para estas três categorias, o incidente é significativo quando:
Os artigos 11.º a 13.º não fixam uma duração mínima expressa para a indisponibilidade total ou limitada.
O incidente é significativo quando:
A duração de um incidente que afete a disponibilidade deve ser medida desde o início da perturbação da prestação adequada do serviço até à recuperação. Quando não seja possível determinar o início de uma indisponibilidade total, a contagem faz-se desde o momento em que a entidade a detetou. A disponibilidade limitada pode resultar, nomeadamente, de um tempo de resposta consideravelmente superior à média ou da indisponibilidade de parte das funcionalidades, devendo ser usados, sempre que possível, critérios objetivos baseados no desempenho normal do serviço.
Para os critérios relativos a cloud, CDN, MSP, MSSP, mercados em linha, motores de pesquisa, redes sociais e serviços de confiança, o número de utilizadores afetados deve considerar:
Quando não seja possível calcular o número de utilizadores afetados, deve ser usada a estimativa do número máximo de utilizadores que possam ter sido afetados. Nos serviços de confiança devem ser consideradas também as partes confiantes.
Os prazos de notificação começam quando a entidade toma conhecimento do incidente significativo. Segundo o considerando 31, esse conhecimento existe quando, após uma avaliação inicial efetuada em tempo útil, a entidade dispõe de um grau razoável de certeza de que ocorreu um incidente significativo.
Em Portugal, o Decreto-Lei n.º 125/2025, de 4 de dezembro, aprovou o Regime Jurídico da Cibersegurança que transpõe a NIS2. O diploma entrou em vigor em 3 de abril de 2026.
O Regulamento n.º 756/2026, de 22 de junho, em vigor desde 23 de junho de 2026, determina expressamente que, para as entidades pertinentes abrangidas pelo Regulamento de Execução (UE) 2024/2690, o impacto significativo de um incidente é definido segundo este ato europeu.
Para essas entidades, a qualificação do incidente deve, portanto, incorporar os critérios gerais, recorrentes e específicos por serviço previstos no regulamento europeu.
Nos termos dos artigos 40.º a 44.º do Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025, e do artigo 20.º do Regulamento n.º 756/2026, a notificação nacional é efetuada através da plataforma eletrónica e compreende, em regra:
Quando o incidente seja resolvido nas duas horas após a deteção, o regime português prevê apenas o envio da notificação do fim do impacto significativo. A entidade deve ainda verificar se o mesmo facto desencadeia obrigações paralelas perante outras autoridades, designadamente em matéria penal, de proteção de dados pessoais, comunicações eletrónicas ou regimes setoriais.
Para uma análise geral do regime europeu e das normas portuguesas, podem ser consultados os artigos Diretiva NIS2 — Diretiva (UE) 2022/2555, Decreto-Lei n.º 125/2025 — Regime Jurídico da Cibersegurança e Regulamento n.º 756/2026 — regras de execução do Regime Jurídico da Cibersegurança.
Em 26 de junho de 2025, a ENISA publicou as orientações técnicas de execução da NIS2 destinadas a apoiar a aplicação do anexo do regulamento. O documento apresenta recomendações práticas, exemplos de evidências e correspondências com normas e referenciais de segurança.
As orientações da ENISA não são juridicamente vinculativas e não substituem o regulamento, a legislação nacional nem as determinações das autoridades competentes. Podem, contudo, apoiar a implementação e a demonstração do cumprimento.
O regulamento não impõe um único modelo documental nem exige, por si só, uma certificação ISO/IEC 27001. As políticas, procedimentos, decisões e registos devem, porém, permitir demonstrar que os controlos foram selecionados, aplicados, acompanhados e revistos de acordo com os riscos.
Consoante a natureza e dimensão da entidade, a documentação e as evidências deverão normalmente permitir demonstrar, quando aplicável:
As entidades potencialmente abrangidas devem:
O artigo 15.º revogou o Regulamento de Execução (UE) 2018/151, que concretizava, ao abrigo da anterior Diretiva NIS1, os elementos de gestão dos riscos aplicáveis aos prestadores de serviços digitais e os parâmetros utilizados para determinar o impacto substancial de um incidente.
O Regulamento de Execução (UE) 2024/2690 não constitui uma simples atualização dos antigos limiares: possui um âmbito subjetivo mais amplo e um anexo técnico muito mais desenvolvido, alinhado com a estrutura das medidas de gestão dos riscos da NIS2.
Regulamento de Execução (UE) 2024/2690 — texto oficial
Diretiva (UE) 2022/2555 — Diretiva NIS2 ou SRI 2
Comissão Europeia — regulamento de execução da NIS2 relativo às entidades e redes críticas
ENISA — orientações técnicas de execução da NIS2
Regulamento de Execução (UE) 2018/151 — regime revogado
Decreto-Lei n.º 125/2025, de 4 de dezembro — Regime Jurídico da Cibersegurança
Regulamento n.º 756/2026, de 22 de junho — execução do Regime Jurídico da Cibersegurança
