Balwurk: “Temos de identificar as atividades críticas e garantir que são testadas para um caso de falha” (com vídeo)

A convergência regulatória europeia está a redefinir o perímetro de responsabilidade dos líderes de segurança. NIS 2, DORA e Cyber Resilience Act não chegam em sequência, mas sim em simultâneo, com exigências que se sobrepõem e calendários que não esperam por uma maturidade organizacional. Ricardo Rodrigues, CEO da Balwurk, apresentou na IT Security Summit 2026 uma leitura integrada do que esta pressão significa na prática.

BCM como função estratégica, não como plano de contingência

A distinção entre uma função estratégica e um simples plano de contingência é, segundo Ricardo Rodrigues, relevante. As organizações que tratam o Business Continuity Management (BCM) como documento de cumprimento regulatório ficam expostas precisamente nos cenários que a regulação pretende cobrir. O modelo funcional, como o business impact analysis, gestão de risco, business continuity plan e disaster recovery plan como sistema interdependente, só cumpre o seu propósito se os parâmetros críticos (MAO e RTO) forem definidos com o negócio, não pela equipa de segurança avulso.

“Ao implementar o processo, estamos a precaver para, em caso de crise, ter a resposta adequada e, por outro lado, estarmos preparados para responder imediatamente”, referiu. “O plano de continuidade de negócio começa com estratégia, e não precisa de ser muito complicado; é só pôr no papel aquilo que queremos fazer”.

Ricardo Rodrigues sublinhou um ponto que tende a ser ignorado em implementações feitas à pressa: a documentação tem de existir em formato físico e acessível, até porque quando os sistemas falham, é precisamente o acesso digital que falha primeiro.

O peso regulatório é cumulativo

A NIS 2, transposta pelo Decreto-Lei n.º 125/2025, alarga o âmbito de entidades obrigadas e endurece requisitos de reporte. O DORA impõe resiliência operacional digital ao setor financeiro com especificidade técnica considerável. O CRA vai mais longe: qualquer produto com elementos digitais colocado no mercado da União Europeia fica sujeito a requisitos obrigatórios de segurança por design, gestão de vulnerabilidades e conformidade contínua.

“A nossa experiência tem-nos dito que a continuidade de negócio acaba por ajudar a preencher se não a totalidade, a quase totalidade que as diretivas nos trazem”, explicou Ricardo Rodrigues. “Temos de identificar as nossas atividades críticas e garantir que essas atividades críticas e essenciais estão testadas para um caso de falha e temos a possibilidade de dar uma resposta adequada”.

Para as equipas de segurança, o desafio é gerir a sobreposição de obrigações sem duplicar esforço nem criar lacunas de cobertura, não apenas compreender cada regulamento isoladamente.

DevSecOps e o problema da escala

A integração de SAST, IAST, DAST e SCA no pipeline CI/CD resolve o problema técnico. O problema que persiste é de governança: volume de alertas, priorização por risco de negócio real, e accountability quando uma vulnerabilidade identificada não é mitigada a tempo. O modelo de Intelligent Orchestration que Ricardo Rodrigues apresenta responde exatamente ao tema, à consolidação de visibilidade e sistema de registo de risco que cria um instrumento para a auditoria.

“Temos de ter uma total independência organizacional da área de segurança, a segurança digital tem de fazer parte da estratégia organizacional e ser visível para todos e reportar diretamente à gestão de topo”, afirmou.

A conclusão de Ricardo Rodrigues é a mais difícil de operacionalizar: a segurança precisa de independência organizacional real, reporte direto à gestão de topo, e uma cultura em que os colaboradores não conhecem apenas conheçam a estratégia, mas também acreditam nela. Para quem gere programas de segurança, é o motivo pelo qual os controlos tecnicamente corretos falham na produção.