O novo regime de cibersegurança: o que ficou por fazer

O veredito da consulta pública

Em 14 de abril de 2026 apresentei dez propostas na consulta pública. O veredito chegou — e diz tanto sobre o regulamento quanto sobre o que ainda falta fazer.

Em 14 de abril de 2026 publiquei no LinkedIn Da conformidade normativa à resiliência operacional: 10 propostas para o novo regime de cibersegurança e apresentei essas mesmas dez propostas na consulta pública sobre o Projeto de Regulamento de execução do Regime Jurídico da Cibersegurança (projeto de regulamento de execução do regime jurídico português de cibersegurança, que transpõe a Diretiva (UE) 2022/2555 — NIS 2).

O Centro Nacional de Cibersegurança (CNCS) de Portugal publicou nesse meio-tempo o Relatório de Consulta Pública. Por rigor, é importante fazer o balanço — e fazê-lo separando aquilo que o relatório diz daquilo que eu, como engenheiro, leio nele. São planos distintos e não devem ser confundidos.

Parte I — Os fatos (o que consta do relatório)

Tudo o que segue nesta seção pode ser verificado no Relatório de Consulta Pública e nos documentos do processo. Não há interpretação aqui.

• Enquadramento. Trata-se do regulamento de execução do regime jurídico da cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025, de 4 de dezembro (decreto-lei português), no âmbito da transposição da Diretiva NIS 2.
• Período de consulta. Foi de 10/03/2026 a 22/04/2026, nos termos do n.º 2 do artigo 101 do Código do Procedimento Administrativo português.
• Participação. O CNCS recebeu contribuições de 56 entidades e pessoas físicas.
• Autoria do relatório. Documento assinado pelo coordenador do CNCS, Lino Santos (junho de 2026).
• Veredito sobre as minhas dez propostas. As dez foram classificadas como “Não acolhido” (não aceita). O relatório fundamenta cada recusa, essencialmente, em três argumentos recorrentes: o regulamento já fixa medidas mínimas obrigatórias, “aplicáveis de forma abrangente, transversal e pretendendo abarcar o maior número de situações”; a verificação da sua aplicação “leva em conta o princípio da proporcionalidade”; e cabe a cada entidade, em função da sua análise de risco residual, implementar medidas mais exigentes.
• As alterações no eixo da gestão de risco. No conjunto do processo, o regulamento sofreu dezenas de alterações de redação aceitas ou parcialmente aceitas (entre outros, os artigos 6, 13 a 17, 22 a 28 e 30, e vários controles do Anexo III). No eixo que me ocupa — gestão do risco residual e inventário de ativos — as duas alterações de substância foram: artigo 31 — redação esclarecida para passar a referir expressamente a análise e a gestão do risco de cibersegurança e do risco residual, partindo da lógica de processos e funções críticas; artigo 32 — redação alterada, restringindo a obrigação de listagem de ativos aos diretamente acessíveis ao público pela internet (contribuição em que, entre outras, a posição da MEO foi parcialmente aceita).

Este é o registro factual. As minhas dez propostas não foram aceitas enquanto tais. A rigor, porém, um dos vetores que defendi viu o texto se mexer: o controle PR.FC-2 (capacitação de pessoal com funções especializadas), no centro da minha Proposta 9, foi alterado — ainda que o relatório credite a alteração a contribuições da ANA, da E-REDES, dos CTT e da Aliança para a Cibersegurança, e não à minha. A formulação “10/10 não aceitas” é, portanto, formalmente exata; em substância, o regulamento se moveu em matéria que eu sinalizei, sem referenciá-la.

Parte II — A análise (a minha leitura de engenharia)

Nota metodológica. Tudo o que segue é análise de minha responsabilidade. A “leitura de convergência” abaixo resulta do cruzamento que eu mesmo faço entre a minha contribuição e as contribuições públicas de outras entidades. Não é uma constatação formal do CNCS, que aprecia as contribuições entidade por entidade e não as agrega por vetor de risco.

1. Não estive sozinho no diagnóstico — e isso é verificável

O que a Tabela 1 mostra. Três vetores de risco em que outros participantes da consulta chegaram, por conta própria, ao mesmo diagnóstico das dez propostas, e o veredito que o CNCS deu a essas contribuições: normas de referência para TO, propostas pela Siemens e pela Universidade do Minho (não aceitas); maturidade e evidências na cadeia de suprimentos, pela JCF, pela TAG e pela SPMS (não aceitas ou parcialmente aceitas); e resiliência das comunicações em cenário de falência do sistema, pela EDP (aceita).

A minha leitura — e assumo-a como leitura — é a de que a comunidade da engenharia pesada e os operadores de infraestrutura identificaram, de forma independente, os mesmos pontos cegos. Imponho-me, contudo, uma distinção: houve convergência no diagnóstico, não necessariamente no remédio. Várias entidades tocaram em TO e na cadeia de suprimentos, mas às vezes pediam soluções no sentido oposto ao meu — a NOS, por exemplo, pediu que a gestão de risco da cadeia fosse “calibrada ao impacto, à criticidade e à natureza dos fornecedores”, isto é, mais margem; eu defendia o inverso, um piso normativo. É justamente isso que singulariza a minha contribuição: onde a maioria pedia flexibilidade, eu pedia um mínimo prescritivo calibrado à consequência física. O fato de a Siemens ter pedido normas de referência específicas para TO, e de o regulador tê-las recusado com o argumento da abrangência genérica, é o sintoma central do problema que descrevo a seguir.

2. A incoerência da proporcionalidade: o argumento que vira a chave do regulador contra a própria decisão

O CNCS recusou a diferenciação TO/TI (a minha Proposta 1) afirmando que o regulamento “já responde à necessidade de segregação de redes, à exigência de zero trust e à gestão de risco de ativos, incluindo legacy e TO”, e que “as medidas pretendem ser o mais abrangentes possível”. Invoca, ao mesmo tempo e de forma transversal, o princípio da proporcionalidade.

É exatamente aqui que está a contradição interna — e este é o ponto técnico que quero deixar claro:

Abrangência transversal e proporcionalidade não são a mesma coisa. Tendem a ser opostas.

A proporcionalidade, a rigor, exige que a medida seja calibrada à consequência da falha. O regulamento não ignora a diferenciação — estratifica as medidas nos níveis Básico, Substancial e Elevado, indexados à Matriz de Risco e à qualificação da entidade. O problema não é, portanto, a ausência de diferenciação; é o eixo segundo o qual ela é feita. Os níveis do QNRCS (Quadro Nacional de Referência para a Cibersegurança, o referencial nacional português de cibersegurança) escalam pela qualificação da entidade; a consequência ciberfísica, porém, não reside na entidade — reside no ativo. Um mesmo operador essencial abriga, sob o mesmo nível de conformidade, um servidor de e-mail e um CLP (controlador lógico programável) que comanda os disjuntores de uma subestação de alta tensão ou as comportas de um porto — e a consequência física de comprometer cada um é incomensurável. É essa a variável que a diferenciação por entidade não captura e que a proporcionalidade obriga a ponderar: o impacto ciberfísico no nível da zona e do conduto, não da pessoa jurídica.

A própria engenharia já resolveu esse problema. A norma ISA/IEC 62443-3-2 põe em prática a proporcionalidade por meio de zonas e condutos com Target Security Levels (SL-T, níveis de segurança-alvo) atribuídos por avaliação de risco. Em outras palavras: a norma técnica que materializa o princípio da proporcionalidade em ambiente de TO é exatamente aquela que o regulamento se recusou a referenciar.

O que a Figura 1 mostra. À esquerda, a zona de TI (servidor de e-mail, sistemas corporativos), cujo nível de segurança é definido pela qualificação da entidade. À direita, a zona de TO (um CLP que comanda um disjuntor, uma comporta portuária, uma subestação de alta tensão), onde o que conta é a consequência física de uma falha. Entre as duas, um conduto com validação humana. A barra de baixo mostra a consequência da falha crescendo da TI para a TO. A frase do rodapé resume: o nível de segurança-alvo (SL-T) deve ser calibrado à zona, não à entidade — proporcionalidade é calibrar, não nivelar.

Daí a minha conclusão analítica: ao remeter a diferenciação de TO para “a proporcionalidade aferida na fase de verificação”, o regulador não aplicou a proporcionalidade — adiou-a, transferindo para o engenheiro de operação em campo uma decisão que deveria ter um piso normativo. Não atribuo má-fé ao CNCS; aponto uma incoerência de princípio que ainda pode ser corrigida por meio de uma instrução técnica.

3. O que defendi, com o devido rigor técnico

O que a Tabela 2 mostra. As dez propostas, cada uma com o controle do projeto de regulamento a que se refere; as contribuições de outros participantes que apontavam no mesmo sentido; o veredito que o CNCS deu a essas contribuições; e, na última coluna, o veredito sobre a proposta do autor: “não aceita” nas dez.

Placar formal. As dez propostas foram integralmente indeferidas (10/10 “Não acolhido” (não aceita)), com uma fundamentação-padrão invariável do CNCS: “o regulamento já responde / as entidades podem implementar medidas mais exigentes em função da análise de risco”. Não houve uma única aceitação direta — ainda que, como notei na Parte I, o texto tenha se mexido num vetor que sinalizei (PR.FC-2), por meio de outros participantes.

Convergência (6 das 10). As propostas 1, 2, 4, 5, 8 e 9 foram corroboradas por terceiros — operadores e fabricantes de referência no domínio das infraestruturas críticas: BSO Consulting, Thales, Siemens, RS, APRITEL, NOS, E-REDES, CTT, ANA Aeroportos, TAG, JCF e a Aliança para a Cibersegurança. O núcleo técnico da contribuição não era marginal: coincidia com a leitura de engenharia da própria indústria.

Contraste determinante. Nos mesmos controles em que propus (PR.FC-2 capacitação, PR.GA-3 MFA, GR.CA-7 cadeia de suprimentos), o CNCS aceitou ou aceitou parcialmente — mas sempre por meio dos outros participantes. A linha de fratura não é técnica, é da natureza do pedido: as contribuições aceitas pediam esclarecimento ou correção de redação de controles já existentes; eu propus acréscimos normativos (novas obrigações de texto, de nível “Elevado”). O regulador rejeitou sistematicamente a criação de novas obrigações, remetendo-as à autonomia da entidade e ao princípio da proporcionalidade.

Propostas pioneiras (6, 7 e 10). Transição pós-quântica (PQC), seguro cibernético e integridade de IA e de algoritmos foram propostas só por mim — nenhum dos outros 55 participantes as levantou. Foram indeferidas com o mesmo argumento genérico de remissão para a análise de risco da entidade, sem apreciação substantiva do mérito prospectivo. É o indicador mais claro de antecipação em relação ao conjunto das contribuições: matéria que o regulamento de execução, nesta versão, optou por não detalhar.

Aproveito o balanço para precisar três pontos que, na sua formulação de divulgação, mereciam maior rigor de engenharia. Faço-o de propósito: a credibilidade técnica também se constrói corrigindo a si mesmo.

Sobre o OOBM e a recuperação (Proposta 3). A rede de gerenciamento Out-of-Band (OOBM, fora de banda) não é, em si mesma, capacidade de black start (partida autônoma). O black start é um procedimento de recomposição do sistema elétrico (unidades com partida própria, ilhamento e ressincronização controlados). O que o OOBM garante é o plano de comando e telemetria segregado que permite à equipe de operação manter observabilidade e manobra remota durante uma recomposição, mesmo com a rede de produção comprometida por ransomware. É um habilitador da resposta, não o ato de recomposição. A formulação correta importa, porque é ela que distingue uma exigência regulatória implementável de uma promessa difusa.

Sobre a automação e a estabilidade da rede (Proposta 4 — Human-in-the-Loop). Esta proposta não é autônoma: é a consequência que justifica a Proposta 1. A minha preocupação é enunciada como cenário, não como fato consumado: caso uma decisão automatizada de mitigação tivesse autoridade de disparo direto sobre a geração síncrona, a subida resultante do RoCoF (taxa de variação da frequência) numa rede com elevada penetração de eletrônica de potência poderia comprometer a estabilidade dinâmica. Vale sublinhar que uma arquitetura correta de zonas e condutos (Proposta 1) impediria, de saída, que um controle de mitigação de TI exercesse comando destrutivo direto sobre TO — razão pela qual os dois pontos são, no fundo, um só: é para barrar esta cadeia causal — falso positivo → disparo → perda de geração → instabilidade dinâmica — que a decisão destrutiva em TO não pode dispensar ao mesmo tempo a validação humana e a segmentação que a confine. A resposta do regulador (medida DE.MC-7, que devolve à entidade a gestão dos falsos positivos) confirma a lacuna: existe a faculdade, falta o piso.

Sobre o vetor das credenciais (Proposta 5). Mantenho a defesa de MFA resistente a phishing (FIDO2/PKI) para perfis de administração. Evito, por rigor, números de efeito: basta constatar que o comprometimento de credenciais continua, de forma recorrente, entre os principais vetores de acesso inicial relatados na telemetria de incidentes do setor (linha coerente com sucessivas edições do Verizon DBIR). Não é preciso uma porcentagem para justificar a medida; basta a engenharia de risco.

Conclusão: a proporcionalidade bem entendida é o caminho, não o obstáculo

O regulamento é um marco. Mas o seu ponto mais frágil não é a ambição — é o eixo da sua diferenciação. Ao estratificar as medidas pela qualificação da entidade e não pela consequência ciberfísica do ativo, trata a Tecnologia Operacional como um caso particular do regime de TI — o que é incompatível com o próprio princípio da proporcionalidade que o regulador invoca para justificá-lo.

A correção não exige reabrir a lei. Exige uma instrução técnica que dê autonomia ao regime de TO, ancorada na IEC 62443-3-2 e na lógica de zonas e condutos com níveis de segurança calibrados à consequência física da falha. É a proporcionalidade — desta vez aplicada, e não adiada.

A resiliência não se decreta numa folha de papel; constrói-se com rigor e engenharia em campo. As dez propostas não foram aceitas. O diagnóstico que as sustenta, esse, continua de pé.

Fico à inteira disposição para o aprofundamento técnico que se julgue oportuno.

— Gaspar do Amaral

Referências normativas

• Diretiva (UE) 2022/2555 (NIS 2)
• Decreto-Lei n.º 125/2025, de 4 de dezembro (regime jurídico português da cibersegurança)
• Relatório de Consulta Pública do regulamento de execução do RJC (regime jurídico da cibersegurança), CNCS (junho de 2026)
• ISA/IEC 62443-3-2 — Security risk assessment for system design (zonas, condutos e SL-T)
• NIST SP 800-207 — Zero Trust Architecture
• ANSI/TIA-942 — redundância de infraestrutura de data center, incluindo percursos de distribuição redundantes (Tier III/IV)
• ISO 22301 / NIST SP 800-34 — continuidade de negócios e planejamento de contingência (diversidade de percurso e recuperação)
• Verizon Data Breach Investigations Report (DBIR) — vetores de acesso inicial

As dez propostas originais foram apresentadas à consulta pública em 14 de abril de 2026. Este texto é o balanço técnico do respectivo veredito.

Nota metodológica

O que é esta página. Adaptação para o português do Brasil do artigo que o autor publicou no LinkedIn em 25 de junho de 2026; a versão integral em português de Portugal está neste site.

Tabelas e figura. As duas tabelas e a figura do original eram imagens com textos em português de Portugal; foram redesenhadas com o mesmo conteúdo, adaptado. Reproduzem a leitura que o autor faz do Relatório de Consulta Pública do CNCS (junho de 2026), não uma agregação oficial do regulador. Os parágrafos “O que a Tabela 1 mostra”, “O que a Tabela 2 mostra” e “O que a Figura 1 mostra” foram acrescentados na adaptação para explicar cada imagem, segundo a regra do autor para os seus artigos; não acrescentam fatos novos.

Nomes das leis e rótulos. Os instrumentos portugueses ficam com o nome oficial de Portugal. Os vereditos do CNCS são citados como no relatório (“Não acolhido”, não aceita). Os códigos como PR.FC-2, PR.GA-3, GR.CA-7, ID.GA-2 e DE.MC-7 identificam controles do Anexo III do regulamento e ficam como no original. Usa-se TI/TO (tecnologia da informação / tecnologia operacional) onde o original usa IT/OT.

Referências

1. Gaspar do Amaral — Da conformidade normativa à resiliência operacional: 10 propostas para o novo regime de cibersegurança (14/04/2026) — as dez propostas apresentadas na consulta pública
2. Centro Nacional de Cibersegurança — Regulamento do Regime Jurídico da Cibersegurança (consulta pública) — Relatório de Consulta Pública e documentos do processo (em português de Portugal)

Gaspar do Amaral · Original em português de Portugal de 25 de junho de 2026, publicado neste site; adaptação emitida em 27 de outubro de 2026 · Figuras e tabelas © Aprecisa.com · Com recurso a IA