Da lista de requisitos ao framework
No início normalmente há 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 todo ano. A partir desse documento nasce um framework próprio, transformando cada requisito em pontos de controle.
Na prática, funciona bem cadastrar um requisito por ponto de controle. Se um parágrafo contiver várias obrigações, por exemplo sobre criptografia, registro de logs e retenção, divida-o. Só assim será possível mostrar depois, para cada obrigação, um status e uma evidência próprios. Use a numeração da fonte como identificador. Assim, sua empresa e seu cliente falam do mesmo requisito.
Formule cada ponto de controle como uma pergunta verificável. A obrigação de garantir uma segurança adequada vira, por exemplo, a pergunta sobre se os dados dos clientes são criptografados durante a transmissão. Esclareça com o cliente os requisitos pouco claros antes de respondê-los.
Se a lista de requisitos já existir em uma tabela, você não precisa digitá-la de novo. O Sightadel permite importar arquivos do Excel e do Word. Depois, verifique cada ponto importado quanto à divisão e à formulação.
Reaproveitar o trabalho existente
O maior benefício de um framework próprio vem dos vínculos. Muitos requisitos de clientes exigem coisas que você já implementa para a ISO 27001, a NIS2 ou o GDPR: controle de acesso, backups, treinamentos, gestão de incidentes, contratação de operadores de dados. As evidências correspondentes já estão na biblioteca de evidências.
Por isso, percorra o framework próprio primeiro em busca do que já existe. Quando um requisito estiver comprovado por uma evidência, vincule-a. A evidência é mantida em um único lugar e, quando vence, isso aparece em todos os frameworks ao mesmo tempo.
Verifique com cuidado se a evidência realmente atende ao requisito do cliente. Os clientes muitas vezes são mais rigorosos ou mais concretos 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 lacunas reais. Responda a elas com honestidade na avaliação e crie planos de ação. Assim você tem uma visão clara do que precisa fazer a mais para esse cliente.
Frameworks próprios diante de clientes e auditores
Um framework próprio não é uma norma certificável. É um instrumento de trabalho com o qual você mostra a clientes, à matriz ou à própria direção em que medida atende a determinados requisitos.
Se um cliente perguntar, você pode mostrar para cada um dos requisitos dele o status, a resposta e a evidência. Para uma auditoria de fornecedores feita pelo cliente, é uma boa preparação, porque a estrutura segue a lista do próprio cliente. As evidências que você pretende compartilhar devem ser verificadas antes quanto a conteúdo confidencial.
Também na auditoria de certificação um framework próprio pode ter um papel. A ISO 27001 exige, por exemplo, que os requisitos das partes interessadas sejam considerados, e entre eles estão as exigências contratuais dos clientes. Com a função “Auditor externo”, o auditor vê os conteúdos do escopo da auditoria, incluindo os frameworks próprios, e os comenta.
O mesmo vale para checklists internos, por exemplo uma autoavaliação anual das unidades. Crie a avaliação com pessoa responsável e prazo, os envolvidos respondem aos pontos de controle e o progresso fica visível em um 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 padronizados. O Sightadel inclui ISO 27001, ISO 9001, ISO 42001, NIS2, GDPR, 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 de IA (EU AI Act).
Um segundo erro é uma estrutura genérica demais. Um ponto de controle que agrupa cinco obrigações só pode ser respondido como um todo. Uma parte está atendida, outra não, e a resposta fica imprecisa. É melhor dividir.
Em terceiro lugar, muitas vezes falta manutenção. Os requisitos dos clientes mudam a cada novo contrato; as exigências do grupo, a cada nova versão. Defina quem mantém o framework atualizado e registre em qual versão da fonte ele se baseia.
Em quarto lugar, nem sempre faz sentido ter um framework próprio por cliente. Se os requisitos de vários clientes forem muito parecidos, um framework comum com os requisitos mais exigentes de cada um pode ser mais claro. Além disso, o número de frameworks próprios depende da sua edição.
