A maioria das ferramentas de compliance organiza o trabalho por framework: uma lista para a ISO 27001, outra para o RGPD, outra para a NIS2. O resultado é trabalho triplicado e evidência espalhada. A iComply inverte o modelo: organiza por controlo, e os frameworks passam a ser vistas sobre os mesmos controlos.

O modelo de dados

Quatro objetos e as relações entre eles sustentam tudo o resto:

Requisito — uma cláusula concreta de uma norma ou lei (ex. ISO 27001 A.5.17, RGPD Art. 32, NIS2 Art. 21).
Controlo — a medida operacional que a organização implementa (ex. “MFA imposta em todos os acessos remotos”).
Risco — o que o controlo mitiga, com probabilidade, impacto e apetite.
Evidência — a prova documental de que o controlo está a funcionar.

As relações são de muitos-para-muitos: um controlo satisfaz vários requisitos, um requisito pode exigir vários controlos, uma evidência pode servir vários controlos. É esta topologia que elimina duplicação.

Um exemplo concreto

Considere o controlo “Autenticação multifator imposta”. Uma vez implementado e com evidência anexada, ele satisfaz simultaneamente:

ISO 27001 — A.5.17 (informação de autenticação)
NIS2 — Art. 21 (medidas de gestão de risco)
DORA — requisitos de gestão de risco TIC
SOC 2 — CC6.1 (controlos de acesso lógico)
RGPD — Art. 32 (segurança do tratamento)
CIS Controls — Control 6 (gestão de acessos)

Numa ferramenta orientada a frameworks, teria de responder seis vezes à mesma pergunta e carregar seis vezes a mesma prova. Aqui responde uma vez.

Estados de um controlo

Cada controlo tem um estado que alimenta diretamente o painel e os relatórios:

Não iniciado — identificado mas sem trabalho.
Em implementação — trabalho em curso, com responsável e prazo.
Implementado — a funcionar, com evidência válida anexada.
Em revisão — atingiu a cadência de revisão e aguarda validação.
Não conforme — falhou teste ou auditoria; gera automaticamente uma ação CAPA.
Não aplicável — fora de âmbito, com justificação registada para o auditor.

Como mapear um controlo

Abra Controlos → Biblioteca e selecione o controlo.
No separador Mapeamento, veja os requisitos já associados pelas bibliotecas oficiais dos frameworks.
Adicione mapeamentos manuais onde a sua realidade for específica — por exemplo, um requisito de legislação nacional.
Classifique a força do mapeamento: satisfaz totalmente, satisfaz parcialmente, ou contribui. Um requisito satisfeito apenas parcialmente continua a aparecer como incompleto até ser coberto por outro controlo.

Não precisa de fazer este trabalho a partir de zero. A iComply traz mapeamentos pré-construídos entre os frameworks suportados; o seu trabalho é validar e complementar.

Controlos personalizados

Além das bibliotecas oficiais pode criar controlos próprios — por exigência contratual de um cliente, por política interna ou por legislação setorial. Um controlo personalizado comporta-se exactamente como qualquer outro: aceita evidência, entra em auditorias e pode ser mapeado a requisitos.

Recomendação: antes de criar um controlo novo, verifique se já existe um que cobre a mesma medida. Bibliotecas inchadas com controlos quase-duplicados são a principal causa de programas de governance que se tornam impossíveis de manter.

Ligar controlos a riscos

Em Risco → Registo associe cada risco aos controlos que o mitigam. Isto produz dois efeitos importantes:

Risco residual calculado — o risco inerente é reduzido em função da eficácia dos controlos associados, em vez de ser estimado à mão.
Priorização automática — quando um controlo falha, os riscos que dependem dele sobem imediatamente, mostrando onde atuar primeiro.

Cadências e garantia contínua

Um controlo sem cadência é uma fotografia; com cadência é um sinal vital. Defina a periodicidade de revisão em função da criticidade — mensal para acessos privilegiados, anual para uma política de topo. Quando a data chega, a plataforma notifica o responsável, o estado passa a Em revisão e o painel reflete-o.

É este mecanismo que substitui a corrida das semanas antes da auditoria por um regime de trabalho estável.

Boas práticas

Um controlo, uma medida. Se a descrição do controlo tem “e” várias vezes, provavelmente são dois controlos.
Escreva controlos operacionais, não aspiracionais. “MFA imposta em todos os acessos remotos” é auditável; “reforçar a segurança de acessos” não é.
Atribua sempre um responsável nominal. Controlos sem dono não são executados.
Não force mapeamentos. Marcar um requisito como satisfeito quando o controlo só contribui parcialmente cria falsa confiança e é detetado em auditoria.
Reveja a biblioteca uma vez por ano. Elimine duplicações e controlos que deixaram de ser aplicáveis.