Arranque do NIS2 Cybersecurity Compliance Toolkit no Odoo: um caso de ponta a ponta

O caso: a Metalúrgica Ribera instala o toolkit

Exemplo Caso ilustrativo: a empresa e os seus dados são inventados para explicar o fluxo.

A Metalúrgica Ribera é uma empresa inventada que fabrica peças para outras indústrias e já trabalha com Odoo. A sua responsável de sistemas, a Laura, instala o NIS2 Cybersecurity Compliance Toolkit para ter num único sítio o perfil da empresa, os controlos, os riscos, a formação e os incidentes. O percurso que se segue é o que ela faz durante o arranque: os nomes dos ecrãs, colunas, campos e estados são os do módulo; as decisões da Laura são ilustrativas.

Antes de instalar, a Laura confirma a sua versão. O módulo está publicado no Odoo Apps para Odoo 17, 18 e 19, a 49 € sem IVA em cada uma dessas versões, pagamento único por versão. Se ainda tens dúvidas sobre se se adapta a ti, tens tudo detalhado em se o toolkit se adapta à tua empresa.

Primeiro registo: o perfil da empresa

A Laura começa pela lista de perfis de empresa. As colunas que vê são entidade legal, empresa, estado-membro, setor, dimensão, estado de aplicabilidade, estado do perfil e responsável, com uma barra de pesquisa e o botão Novo. Essas colunas dizem-lhe que dados tem de levar preparados: qual é a entidade legal, em que estado-membro opera, o seu setor, a sua dimensão e quem se encarrega do perfil.

O campo em que mais se demora é applicability_status. Os valores que o módulo define são Potentially In Scope, Likely Out of Scope, Needs Legal Review, Essential Entity Candidate (Annex I), Important Entity Candidate (Annex II) e Confirmed by Legal Counsel. Repara nas etiquetas: falam de «candidata» e de revisão jurídica. A app guarda a avaliação que tu registas. A Laura deixa o perfil em Needs Legal Review e anota que o mudará para Confirmed by Legal Counsel quando o seu consultor jurídico lho confirmar.

Segundo passo: os controlos e o seu estado de maturidade

A lista de controlos tem colunas de categoria, nome do controlo, estado de maturidade, responsável e revisão. O estado de maturidade (maturity_status) admite Not Implemented, Planned, Partially Implemented, Implemented e Not Applicable.

A Laura percorre os controlos com a sua equipa, um a um, e define um critério próprio para não hesitar em cada linha:

• Implemented só se puder mostrar como o fazem hoje.
• Partially Implemented se existe, mas não cobre tudo o que o controlo descreve.
• Planned se houver uma pessoa e uma data comprometidas.
• Not Applicable se não se aplica à sua atividade e sabe explicar porquê.
• Not Implemented para tudo o resto.

Em cada linha preenche também o responsável, porque a coluna está na lista e quer ver de relance quem leva cada controlo.

Terceiro passo: o registo de riscos

A lista Risk Register mostra impacto, probabilidade, risco residual, decisão de tratamento e estado, com o botão New e a pesquisa. Os estados que o módulo define para este conjunto são Draft, Under Review, Accepted e Closed.

A Laura regista cada risco em Draft com o seu impacto e a sua probabilidade. Move-o para Under Review quando o apresenta à direção e para Accepted quando há uma decisão de tratamento acordada. Os que já não se aplicam deixa-os em Closed em vez de os apagar, para conservar o rasto.

Formação: os Training Records

A lista de Training Records tem colunas de nome, tipo, artigo e estado, com o botão New e o pesquisador. Os estados são Assigned, In Progress, Completed, Overdue e Exempt.

A Laura cria um registo por cada formação que o pessoal tem de fazer e marca como Exempt quem não está abrangido, em vez de o deixar sem registo. Assim, quando filtra a lista, o que não está em Completed nem em Exempt é trabalho pendente.

Incidentes: a lista e os estados que o módulo define

A lista de incidentes tem colunas de referência, hora de deteção, gravidade, estado e avaliação de significância, mais o botão Novo e o pesquisador.

Entre os conjuntos de estados que o código do módulo define há um com Detected, Triage, Under Investigation, Reportable Decision Pending, Reported, Closed e False Positive, e um campo root_cause_status com Unknown, Under Investigation, Identified e Not Applicable. A Laura abre um incidente de teste na sua base de dados de testes para ver que valores lhe oferece a coluna de estado antes de o explicar à equipa. Se quiseres ver a estrutura completa do módulo, tens-a em como funciona o toolkit por dentro.

A primeira semana: o que a Laura reviu

Com tudo registado, a Laura reserva um bocado de cada dia da primeira semana para rever:

• Que o perfil da empresa tem preenchidos entidade legal, estado-membro, setor, dimensão e responsável.
• Que applicability_status reflete o que disse o consultor e não uma suposição.
• Que nenhum controlo ficou sem responsável na lista de controlos.
• Que os controlos em Planned têm uma pessoa por trás.
• Que os riscos em Draft passaram a Under Review ou têm data para o fazer.
• Que formações aparecem em Overdue e a quem é preciso ligar.
• Que o incidente de teste ficou na base de dados de testes e não na de trabalho.

O que aprender com o caso

A ordem que a Laura segue (perfil, controlos, riscos, formação, incidentes) é uma escolha sua, pensada para ir do geral ao diário. O que vem do módulo é o que tens de preencher e perceber: as colunas de cada lista e os valores de cada estado. Três ideias para levares:

• Os estados são decisões de pessoas. Define um critério por escrito antes de começar, sobretudo para maturity_status.
• O estado de aplicabilidade precisa do teu consultor. As etiquetas do próprio módulo deixam isso claro com Needs Legal Review e Confirmed by Legal Counsel.
• Um responsável por linha. As listas de perfis e controlos têm essa coluna; usa-a.

Como a FlexigoTech te ajuda

A FlexigoTech implementa Odoo e desenvolve conectores e integrações à medida. Se quiseres ajuda para carregar os teus controlos e riscos, ou para ligar o toolkit a outras partes do teu Odoo, tens o módulo na nossa página e na sua ficha do Odoo Apps.

Continue a ler