Da lista de requisitos ao framework
No início está normalmente um documento: uma política do grupo, um anexo de segurança ao contrato com um cliente ou um questionário que um cliente envia todos os anos. A partir desse documento nasce um framework próprio, transpondo cada requisito para pontos de controlo.
Provou-se eficaz registar um requisito por ponto de controlo. Se um parágrafo contiver várias obrigações, por exemplo sobre cifragem, registo de eventos e conservação, divida-o. Só assim será possível mostrar mais tarde, para cada obrigação, um estado e uma evidência próprios. Adote a numeração da fonte como identificador. Assim, a sua empresa e o seu cliente falam do mesmo requisito.
Formule cada ponto de controlo como uma pergunta verificável. A obrigação de garantir uma segurança adequada torna-se, por exemplo, a pergunta sobre se os dados dos clientes são cifrados durante a transmissão. Esclareça com o cliente os requisitos pouco claros antes de lhes responder.
Se a lista de requisitos já existir numa tabela, não precisa de a transcrever. O Sightadel permite importar ficheiros Excel e Word. Depois, verifique cada ponto importado quanto à divisão e à formulação.
Reutilizar o trabalho existente
O maior benefício de um framework próprio resulta das associações. Muitos requisitos de clientes exigem coisas que já implementa para a ISO 27001, a NIS2 ou o RGPD: controlo de acessos, cópias de segurança, formação, gestão de incidentes, subcontratação. As evidências respetivas já estão na biblioteca de evidências.
Percorra, por isso, o framework próprio primeiro à procura do que já existe. Quando um requisito estiver comprovado por uma evidência, associe-a. A evidência é mantida num único lugar e, quando expira, isso vê-se em todos os frameworks ao mesmo tempo.
Verifique com cuidado se a evidência cumpre realmente o requisito do cliente. Os clientes formulam muitas vezes de forma mais rigorosa ou mais concreta do que uma norma. Se um contrato exigir, por exemplo, um prazo determinado para informar o cliente sobre incidentes, um processo genérico de gestão de incidentes não basta. Nesse caso, complemente o processo e a evidência.
O que fica em aberto depois disso são as verdadeiras lacunas. Responda-lhes com honestidade na avaliação e crie planos de ação. Fica assim com uma imagem clara do que tem de fazer a mais para esse cliente.
Frameworks próprios perante clientes e auditores
Um framework próprio não é uma norma certificável. É um instrumento de trabalho com que mostra a clientes, à empresa-mãe ou à própria gestão em que medida cumpre determinados requisitos.
Se um cliente perguntar, pode mostrar para cada um dos seus requisitos o estado, a resposta e a evidência. Para uma auditoria a fornecedores feita pelo cliente, é uma boa preparação, porque a estrutura segue a lista do próprio cliente. As evidências que pretenda partilhar devem ser previamente verificadas quanto a conteúdos confidenciais.
Também na auditoria de certificação um framework próprio pode ter um papel. A ISO 27001 exige, por exemplo, que se tenham em conta os requisitos das partes interessadas, e entre eles estão as exigências contratuais dos clientes. Com a função «Auditor externo», o auditor vê os conteúdos, incluindo os frameworks próprios, e pode comentá-los, sem nunca apagar nada.
O mesmo se aplica a catálogos de verificação internos, por exemplo uma autoavaliação anual das instalações. Crie a avaliação com pessoa responsável e data limite, os envolvidos respondem aos pontos de controlo e o progresso fica visível num só lugar.
Erros típicos na criação
O erro mais frequente é criar um framework próprio para algo que já existe. Antes de criar, consulte a lista de frameworks normalizados. O Sightadel inclui ISO 27001, ISO 9001, ISO 42001, NIS2, RGPD, BSI C5, DORA, NIST CSF 2.0, SOC 2, HACCP, o § 390 do Código Social alemão, livro V (SGB V), e o Regulamento Europeu da IA (EU AI Act).
Um segundo erro é uma estrutura demasiado grosseira. Um ponto de controlo que agrupa cinco obrigações só pode ser respondido como um todo. Uma parte está cumprida, outra não, e a resposta fica imprecisa. É preferível dividir.
Em terceiro lugar, falta muitas vezes a manutenção. Os requisitos dos clientes mudam com cada novo contrato; as exigências do grupo, com cada nova versão. Defina quem mantém o framework atualizado e registe em que versão da fonte se baseia.
Em quarto lugar, nem sempre faz sentido um framework próprio por cliente. Se os requisitos de vários clientes forem muito semelhantes, um framework comum com os requisitos mais exigentes de cada um pode ser mais claro. O número de frameworks próprios depende, além disso, da sua edição.
