NIS2 internamente ou com uma consultora de implementação? Comparação de custos, prazos e riscos

A decisão entre implementar a NIS2 internamente ou recorrer a uma consultora não se resume a comparar os honorários externos com o custo da equipa interna. O resultado do projeto depende do âmbito das obrigações, da disponibilidade dos decisores, da qualidade dos dados sobre processos e ativos e da capacidade da organização para manter posteriormente as soluções adotadas. A opção aparentemente mais económica pode tornar-se a mais dispendiosa se conduzir a um enquadramento incorreto, à repetição de análises ou à criação de documentação que não corresponde ao funcionamento real da empresa. Por isso, importa começar por determinar o âmbito e identificar as lacunas, comparar depois o custo total, o prazo e o risco dos três modelos de execução e só então escolher quem realizará o trabalho e como o projeto será conduzido.

Não escolha o prestador antes de determinar as obrigações aplicáveis

A comparação entre uma implementação realizada internamente e o apoio de uma entidade externa só é válida depois de se determinar se a organização está abrangida pelas obrigações decorrentes da NIS2 e pela legislação nacional que transpõe esses requisitos. Caso esteja abrangida, é necessário definir quais os serviços, unidades, instalações e ativos incluídos na análise. Sem este enquadramento, não é possível estimar com rigor o volume de trabalho, o prazo de execução ou o custo. A gestão de topo deve igualmente nomear um responsável pelo projeto, com autoridade para articular decisões entre as áreas operacionais, jurídica e de tecnologias de informação.

O ponto de partida não é a compra de documentação ou de uma ferramenta informática, mas a descrição do modelo operacional. É necessário identificar os serviços prestados, os processos, sistemas e dados que os suportam, bem como os fornecedores e as dependências essenciais para a continuidade da atividade. Só este mapeamento permite decidir se a análise deve abranger toda a empresa ou apenas determinados serviços e instalações. A primeira etapa deve resultar num enquadramento documentado da entidade, em limites de âmbito claramente definidos e numa lista das áreas que exigem avaliação e medidas corretivas.

O enquadramento formal na legislação deve ser distinguido da necessidade empresarial de reforçar a resiliência. Uma organização pode não estar abrangida pelas obrigações legais e, ainda assim, ter de responder a requisitos de clientes, do grupo empresarial, de seguradoras ou de outros intervenientes da cadeia de abastecimento. Nesse caso, o projeto não deve ser apresentado como cumprimento de uma obrigação legal, mas como resposta a requisitos contratuais concretos e a riscos operacionais.

Considere-se uma empresa industrial que dispõe de firewalls, cópias de segurança e proteção dos postos de trabalho, mas não consegue identificar o responsável pelo processo de resposta a incidentes. Também não avaliou de que forma uma indisponibilidade do sistema de planeamento da produção afetaria o calendário das ordens, a disponibilidade de materiais e o cumprimento dos prazos de entrega. Neste caso, o problema não se limita ao nível das salvaguardas técnicas: inclui também a ausência de responsabilidades atribuídas e de uma análise das dependências entre o sistema informático e a prestação do serviço.

Depois de descrita a atividade, deve ser efetuada uma avaliação jurídica de acordo com os critérios setoriais, organizacionais e de dimensão vigentes à data da publicação. A posição formal deve ser aprovada pelo órgão ou pela pessoa com poderes para representar a organização, envolvendo a área jurídica e os responsáveis pelos serviços e processos. A equipa de TI fornece os dados relativos aos sistemas, mas não deve decidir isoladamente o enquadramento da entidade. Esta questão é aprofundada no artigo “Diretiva NIS2 — a quem se aplica e que empresas têm de cumprir os novos requisitos?”.

O custo da implementação não termina na fatura

A execução interna não é gratuita, tal como os honorários da consultora não representam o custo total do apoio externo. O cálculo deve incluir o trabalho da gestão de topo, dos responsáveis pelos processos, das equipas de TI, compras, recursos humanos e jurídica, bem como do responsável pelo sistema de gestão. O tempo destas pessoas deve ser valorizado com base nos custos internos e nas horas efetivamente dedicadas, considerando também as tarefas operacionais que deixarão de executar durante o projeto. O esforço depende sobretudo do número de instalações, processos, sistemas, fornecedores e empresas incluídos no âmbito.

Os elementos mais frequentemente subestimados são a recolha de dados, a definição de responsabilidades, o inventário de ativos e fornecedores, a preparação de evidências, a realização de testes e ações de formação e a correção de documentos inconsistentes. Uma consultora só reduzirá este esforço se conseguir integrar os requisitos nos processos, nas funções e nas ferramentas existentes. Entregar modelos genéricos de políticas sem compreender a atividade não elimina o custo: apenas o transfere para as fases de validação, implementação e atualização.

A documentação sobre incidentes pode ser produzida rapidamente, mas será meramente formal se não tiverem sido definidos os regimes de prevenção, os circuitos de escalonamento, a preservação de evidências e as substituições. O custo real surgirá durante um teste ou um incidente, quando for necessário reformular o procedimento. O orçamento deve, por isso, separar os custos pontuais dos recorrentes e incluir os honorários de consultoria, os investimentos técnicos, a indisponibilidade de recursos durante o projeto, as correções e a manutenção anual: revisões, testes, formação, atualização documental, avaliação de fornecedores e gestão de incidentes.

Um sistema de gestão da segurança da informação operacional ou uma certificação pode reduzir o trabalho de inventário, avaliação de riscos, controlo da informação documentada e auditoria, desde que as soluções funcionem efetivamente no âmbito analisado. Contudo, não substitui a avaliação das obrigações concretas previstas na legislação aplicável, nem a verificação de que os controlos existentes são adequados aos serviços abrangidos. Esta relação é explicada no artigo NIS2 e NP EN ISO 27001: o que oferece a certificação e o que ainda falta para a conformidade com a KSC.

O prazo depende da capacidade para tomar decisões

O tempo necessário para preparar a organização para os requisitos da NIS2 raramente depende da rapidez com que se redigem procedimentos. Os principais constrangimentos são a disponibilidade de dados fiáveis, dos responsáveis pelos processos e das pessoas autorizadas a aprovar alterações. O planeamento deve considerar a disponibilidade real destas pessoas, a frequência das reuniões do comité de acompanhamento e o tempo necessário para resolver questões entre departamentos. A data prometida para a entrega da documentação não é uma medida de progresso se a organização ainda não aprovou o âmbito, as responsabilidades e as prioridades.

As atividades devem ser organizadas de acordo com as respetivas dependências. Primeiro, é necessário definir o âmbito, as funções, os processos e os ativos; depois, realizar a avaliação de riscos, aprovar o plano de tratamento do risco, implementar os controlos, executar testes e recolher evidências de funcionamento. Podem avançar em paralelo tarefas assentes nos mesmos pressupostos aprovados, como o inventário de contratos e a revisão dos controlos existentes. Contudo, não deve iniciar-se uma avaliação de riscos detalhada antes de identificar os serviços, processos, sistemas, informação e dependências de fornecedores que serão avaliados.

Na priorização das ações, devem distinguir-se as lacunas que exigem aquisições, alterações contratuais, integrações técnicas ou testes. Cada um destes grupos segue um circuito de aprovação e um prazo de execução diferentes. O apoio externo pode acelerar o diagnóstico, facilitar os workshops e estruturar os resultados, mas o consultor não pode decidir pela gestão de topo quanto à aceitação do risco, à prioridade dos investimentos ou ao tempo de interrupção tolerável na prestação dos serviços. Se estas decisões forem adiadas até ao final do projeto, a documentação avançará mais depressa do que as soluções operacionais e parte das análises terá de ser repetida.

O progresso deve, portanto, ser medido pelo número de decisões aprovadas, dependências resolvidas e controlos cujo funcionamento foi verificado, e não pelo número de documentos produzidos. Mesmo um calendário de poucas semanas será inviável se a organização não tiver uma lista atualizada dos sistemas, um registo dos contratos com fornecedores ou responsáveis pelos processos formalmente definidos. Nesse cenário, a equipa poderá descrever o estado declarado, mas não conseguirá estabelecer responsabilidades pela continuidade, recuperação dos serviços e supervisão dos fornecedores.

O mapeamento de processos deve apoiar estas decisões, e não aumentar desnecessariamente a documentação. A comparação “BPMN ou fluxograma — qual é a melhor ferramenta para mapear processos da qualidade?” ajuda a escolher o nível de detalhe adequado. Neste contexto, a ferramenta correta é aquela que apresenta de forma inequívoca as funções, os pontos de transferência de responsabilidade, as dependências de informação e as áreas que exigem proteção ou substituição.

O risco resulta sobretudo de pressupostos incorretos

O sucesso da preparação para os requisitos da NIS2 depende mais da validade dos pressupostos do que do número de tarefas concluídas. No modelo interno, os principais riscos estão associados a uma interpretação incorreta do âmbito, à omissão de dependências de negócio e à redução da cibersegurança a uma responsabilidade exclusiva da equipa de TI. A organização pode, assim, ignorar processos produtivos, logística, manutenção, continuidade do abastecimento ou compromissos perante clientes. Falta também uma avaliação independente das práticas consideradas internamente suficientes apenas porque, até ao momento, não provocaram perturbações visíveis.

O apoio externo não elimina automaticamente estes riscos. Pelo contrário, o risco aumenta quando o prestador fornece um pacote uniforme de documentos sem compreender os serviços, processos e dependências da organização, não envolve os responsáveis pelos processos ou não transfere os conhecimentos necessários para manter as soluções adotadas. O resultado é um sistema dependente do autor da documentação, e não das pessoas responsáveis pelo funcionamento diário.

É, por isso, recomendável separar a execução dos trabalhos da avaliação final independente, sobretudo quando a mesma entidade definiu o âmbito, avaliou os riscos e selecionou os controlos. A decisão de aceitar o risco residual deve permanecer com o nível de gestão competente.

A conformidade meramente formal revela-se nas divergências entre a documentação e a prática: a política descreve uma atuação diferente do processo real, o registo de riscos não influencia prioridades nem investimentos e o procedimento de gestão de incidentes nunca foi testado. Uma lacuna documental corresponde à inexistência ou incoerência de um registo necessário. Uma lacuna operacional existe quando a organização não consegue executar uma atividade, atribuir a responsabilidade ou apresentar evidências da sua eficácia. Preencher um formulário pode resolver a primeira lacuna, mas não substitui um teste, uma decisão ou uma mudança na forma de trabalhar.

Um exemplo é uma unidade industrial com um procedimento aprovado para comunicar incidentes, mas cujos trabalhadores da produção desconhecem como reportar a indisponibilidade de um sistema de controlo ou planeamento. Em simultâneo, não foram acordados com o prestador do serviço o circuito de escalonamento, os contactos e as regras de atuação fora do horário normal. O documento existe, mas, perante uma perturbação, os primeiros minutos perdem-se a determinar responsabilidades. Esta lacuna só será detetada através de um exercício que envolva o utilizador, o responsável pelo processo, a equipa de TI, a gestão e o fornecedor.

Uma auditoria de preparação deve avaliar a capacidade de atuar e de apresentar evidências credíveis, e não apenas a existência da documentação. Entre os indicadores úteis encontram-se o número de ações pendentes de auditorias e testes anteriores, os resultados dos testes de recuperação, as conclusões das revisões de incidentes e perturbações e a percentagem de fornecedores críticos sujeitos a avaliação e a requisitos acordados — sempre com base nos dados da organização. A forma de conduzir esta verificação é desenvolvida no artigo “Auditoria NIS2 numa empresa industrial — como verificar se a organização está preparada para as novas obrigações”.

O modelo misto proporciona geralmente maior controlo

A escolha do modelo de implementação deve resultar da capacidade real da organização para executar o trabalho, e não apenas da comparação dos honorários de consultoria. A implementação interna é racional quando o projeto tem um responsável competente, os processos de gestão do risco são maduros, os inventários de ativos e dependências estão atualizados e as pessoas-chave dispõem de tempo e capacidade para interpretar os requisitos. Um apoio externo mais abrangente justifica-se quando existem lacunas significativas de competências, uma estrutura dispersa, dependências tecnológicas relevantes, prazos reduzidos ou ausência de um sistema de gestão estruturado.

Na maioria dos casos, o modelo misto proporciona o melhor controlo sobre custos, prazos e riscos. A organização mantém a responsabilidade pelas decisões, pelos dados de origem, pela titularidade dos riscos e pela execução das medidas operacionais. O consultor assume o diagnóstico, a metodologia, a facilitação dos workshops, as análises que requerem conhecimentos especializados e o controlo da qualidade dos resultados.

Devem permanecer na organização, pelo menos:

• a definição da relevância dos processos e serviços;
• a nomeação dos responsáveis pelos riscos;
• a aceitação do risco residual;
• a definição das prioridades de investimento;
• a confirmação de que os controlos funcionam na prática.

A gestão de topo não pode transferir para o prestador a responsabilidade pela resiliência da organização.

Uma empresa com várias unidades pode recolher internamente a informação sobre serviços, ativos, fornecedores e impactos das perturbações, porque a sua avaliação fiável exige conhecimento operacional. Um especialista externo pode depois estruturar o método de avaliação, questionar incoerências, conduzir workshops interdepartamentais e verificar se as evidências estão completas. A relação custo-benefício desta divisão depende do número e das competências das pessoas que podem ser efetivamente alocadas, e não da composição formal da equipa do projeto.

As propostas devem ser comparadas com base no mesmo âmbito de entregáveis e nos mesmos critérios de aceitação. As referências do prestador devem ser avaliadas pela semelhança do setor, da escala, dos processos e do ambiente tecnológico, e não apenas pelo número de projetos realizados. O contrato deve definir claramente os entregáveis, os critérios de aceitação, a obrigação de adaptar as soluções aos processos reais, a transferência de conhecimento, as regras de confidencialidade e de acesso a dados sensíveis, a responsabilidade por correções e o apoio após a implementação. O modelo de remuneração não deve premiar a quantidade de documentos, mas a obtenção dos resultados acordados e verificáveis.

Os limites práticos da responsabilidade da gestão de topo, dos responsáveis pelos processos e das funções de suporte são aprofundados no artigo NIS2 na prática da gestão: como converter requisitos em decisões, responsabilidades e resiliência efetiva da organização.

Baseie a decisão em evidências e na capacidade para manter o sistema

A escolha do modelo de implementação deve ser precedida por um breve diagnóstico organizacional. É necessário confirmar o âmbito do projeto, nomear o respetivo responsável, avaliar a disponibilidade de competências, inventariar as evidências de funcionamento existentes e estimar as lacunas mais relevantes. Só então será possível decidir que atividades podem ser realizadas internamente e onde a intervenção de um especialista reduzirá o risco de interpretação incorreta, omissões ou repetição do trabalho.

A decisão da gestão de topo deve comparar três opções: execução interna, modelo misto e apoio externo mais abrangente. A todas devem ser aplicados os mesmos critérios:

• custo total, incluindo o trabalho das equipas, as correções e a manutenção;
• tempo necessário para atingir capacidade operacional;
• risco de erro e de repetição dos trabalhos;
• disponibilidade efetiva das competências necessárias;
• capacidade da organização para manter autonomamente as soluções.

A deliberação ou decisão da gestão de topo deve identificar o modelo selecionado, a distribuição de responsabilidades, o responsável pelo projeto, os recursos, o método de reporte, os critérios de aceitação e os indicadores de eficácia decorrentes dos processos da organização, e não de limites universais desprovidos de contexto.

A implementação não deve ser aceite com base no número de políticas elaboradas. O resultado esperado é um modo de funcionamento repetível: funções atribuídas, decisões sobre riscos documentadas, controlos implementados, respostas a perturbações e incidentes testadas, supervisão de fornecedores e registos credíveis. Um procedimento de resposta aprovado não comprova a preparação se o teste revelar contactos desatualizados, um circuito de escalonamento pouco claro ou a ausência de uma pessoa autorizada a decidir.

Os critérios de aceitação devem abranger a correspondência entre os documentos e a prática, o tratamento das lacunas acordadas, os resultados dos testes, a transferência de conhecimento e um plano claro de melhoria contínua, incluindo um programa de auditorias internas. As evidências de aceitação podem incluir aprovações, registos, resultados de testes, atas ou comprovativos de formação, decisões relativas aos riscos e confirmações de execução das ações. A preparação e manutenção destas evidências são aprofundadas no artigo Documentação NIS2 e KSC antes de uma inspeção: que políticas, registos e evidências são realmente necessários.

A sustentabilidade da solução só pode ser avaliada quando a intervenção do consultor é reduzida. Nessa fase, os responsáveis pelos processos devem conseguir atualizar autonomamente os registos, tomar decisões sobre riscos, analisar os resultados dos testes e iniciar ações corretivas. Se o sistema só funcionar graças ao conhecimento do prestador, o projeto não está concluído: a organização recebeu documentação, mas não desenvolveu a capacidade necessária para a manter.