Compliance executável: automatize o teste, não a interpretação

O objeto estruturado precisa de conservar o significado

O padrão proposto pela ISACA organiza uma cadeia de seis objetos: requirement, gap check, remediation, risk, control e evidence. A vantagem concreta é tornar relações consultáveis e permitir que um controlo de identidade, logging ou resposta alimente mais de uma obrigação. O risco aparece quando a relação many-to-many é achatada: o mesmo log pode apoiar dois requisitos e ainda assim ter retenção, população ou detalhe insuficientes para um deles.

NIST SP 800-53 fornece um catálogo de controlos, não uma declaração de conformidade europeia. O AI RMF é voluntário e exige processos contínuos de governar, mapear, medir e gerir. OECD pede rastreabilidade adequada ao contexto. As três referências apontam para uma conclusão comum: dados estruturados ajudam a reconstruir decisões; não retiram a necessidade de âmbito, julgamento e accountability.

Desenhe um grafo de prova, não uma folha de checkboxes

Cada requisito deve apontar para a frase normativa exata e para uma interpretação aprovada com data. Cada controlo aponta para implementação e população. Cada teste declara input, regra, frequência e tolerância. Cada evidência guarda proveniência e retenção. A decisão final liga resultado, exceções, risco residual, aprovador e validade. Esta separação permite alterar uma regra sem reescrever o passado.

Evite o campo universal compliant=true. Uma organização pode ter o controlo implementado em 97% da população, uma exceção compensada e um requisito ainda fora de âmbito noutra jurisdição. Guarde estados atómicos e calcule vistas para cada decisão. Quando a interpretação muda, recalcule o estado atual sem apagar a prova histórica.

Comece por um controlo partilhado e uma pergunta difícil

Escolha um controlo real — por exemplo, revogação de acesso quando alguém sai — e mapeie-o a dois requisitos que a organização já acompanha. Recolha população de identidades, eventos de saída, tempos de revogação, falhas, exceções e owner. Depois peça a um auditor interno para repetir o resultado sem ajuda da equipa que escreveu a automação.

Inclua uma pergunta que o código não consegue responder sozinho: a população cobre trabalhadores externos? O relógio começa na notificação ou na data efetiva? Uma conta de emergência tem compensação suficiente? Registe a decisão e transforme apenas a parte objetiva em regra. O sistema deve escalar ambiguidade, não escondê-la num default.

• Mantenha texto normativo e interpretação em campos separados.
• Use relações many-to-many entre requisitos, controlos, testes e evidências.
• Dê prazo a exceções e invalide evidência quando fonte, população ou controlo mudar.
• Teste o motor com dados ausentes, conflito de versões e resultado parcialmente coberto.