Certificação ISO 27001: construir um SGSI duradouro

Um cliente pede o vosso certificado ISO 27001. O prazo comercial é claro; o trabalho de implementação pode não ser. A primeira decisão da gestão é se quer construir um sistema de gestão da segurança que a empresa consiga manter, ou organizar um projeto temporário em torno de uma data de auditoria.

Um plano de certificação útil começa por definir o sistema que precisa de operar e só depois organiza as evidências que o demonstram. Isso significa decidir que serviços o certificado deve abranger, quem pode autorizar decisões de risco, de que recursos precisam os responsáveis pelos controlos e como a gestão vai saber se os controlos funcionam.

O certificado é um resultado importante. O ativo empresarial duradouro é um sistema de gestão da segurança da informação, ou SGSI, que continua útil quando os colaboradores saem, os fornecedores mudam, são lançados novos produtos e os clientes fazem perguntas mais difíceis.

O que a certificação ISO 27001 realmente estabelece

A ISO/IEC 27001 especifica requisitos para estabelecer, implementar, manter e melhorar continuamente um SGSI. O seu objetivo é gerir os riscos para a confidencialidade, integridade e disponibilidade da informação no contexto da organização.

A confidencialidade diz respeito à divulgação indevida, como registos de clientes ficarem acessíveis a utilizadores não autorizados. A integridade diz respeito a alterações inexatas ou não autorizadas, como alguém modificar instruções de pagamento. A disponibilidade diz respeito ao acesso quando é necessário, como restabelecer um serviço importante após uma falha de infraestrutura.

A certificação incide sobre esse sistema de gestão dentro do âmbito declarado. Não garante que todos os produtos estão isentos de vulnerabilidades, que não podem ocorrer incidentes nem que todas as unidades de negócio foram avaliadas. Um certificado que abrange um serviço gerido não deve ser apresentado como garantia para um produto não relacionado.

A ISO e a IEC publicam a norma; não certificam a vossa organização. É um organismo de certificação independente que realiza a avaliação e toma a decisão de certificação. Para dar garantias aos clientes, uma recomendação prática é escolher um organismo acreditado para a atividade de certificação de SGSI em causa e confirmar que a sua certificação satisfaz os requisitos dos compradores.

A distinção entre conformidade e certificação também é importante. Uma organização pode implementar um SGSI que cumpre a norma sem procurar certificação externa. A certificação acrescenta uma avaliação independente e um certificado formal. Comprar software, contratar um implementador qualificado ou concluir uma formação não confere certificação à organização.

Decidir se a certificação resolve o problema do negócio

A certificação é particularmente relevante quando requisitos de contratação, compromissos contratuais, informação sensível ou dependências operacionais justificam uma garantia independente. Não é uma obrigação legal universal para todas as empresas.

Antes de assumir o compromisso, peça às equipas comerciais e de gestão de clientes que identifiquem o requisito concreto. O comprador exige um certificado antes da assinatura do contrato, antes do acesso à produção ou na renovação? Tem de abranger um serviço ou uma entidade jurídica específica? O comprador continuará a exigir um questionário de segurança, relatórios de testes ou controlos contratuais adicionais?

Estas respostas afetam as prioridades de investimento. Um certificado pode apoiar o processo de contratação, mas não elimina toda a due diligence. Evite prever receitas partindo do pressuposto de que a certificação conclui automaticamente a análise de segurança de cada cliente.

Separe a certificação da análise regulamentar. Um SGSI pode apoiar evidências e governação relevantes para outras obrigações, mas a certificação não estabelece a conformidade com o RGPD ou com a NIS2. Esses regimes têm as suas próprias regras de aplicabilidade e deveres. A NIS2 é transposta através da legislação nacional; os deveres decorrentes do RGPD dependem das atividades de tratamento e dos papéis da organização.

A fundamentação para a gestão deve, por isso, identificar três coisas: a garantia de que os clientes precisam, os riscos de informação que a empresa tem de gerir e o custo operacional contínuo. Aprove o programa com essa base, e não com a promessa de um certificado numa data arbitrária.

Definir um âmbito que os clientes compreendam

O âmbito descreve os limites e a aplicabilidade do SGSI. Deve identificar os serviços, unidades organizacionais, localizações, pessoas, informação, sistemas e dependências relevantes. Tem também de ter em conta as interfaces com atividades fora desses limites.

Um âmbito restrito pode ser adequado, sobretudo numa primeira implementação. Ainda assim, tem de refletir aquilo que os clientes esperam que o certificado abranja. Excluir a equipa que administra o acesso à produção não elimina a sua influência sobre um serviço ao cliente incluído no âmbito.

Para uma aplicação alojada, analise toda a cadeia do serviço: desenvolvimento, implementação, operações de produção, acesso de suporte, administração de identidades, cópias de segurança e fornecedores externos significativos. Processos partilhados de RH ou de TI podem afetar a segurança mesmo quando o âmbito se centra num produto e não na empresa inteira.

Um registo de âmbito prático deve responder a estas perguntas:

• Que entidade jurídica opera o serviço?
• Que serviços e informação dirigidos aos clientes estão abrangidos?
• Que localizações e regimes de teletrabalho são relevantes?
• Que equipas e processos partilhados afetam esses serviços?
• Que fornecedores disponibilizam infraestrutura ou tratam informação relevante?
• O que fica fora do limite e como são geridas as respetivas interfaces?

Teste a redação proposta com um colega que lide com compradores. Se essa pessoa não conseguir explicar se o serviço do cliente está abrangido, a redação precisa de ser trabalhada.

Não otimize o âmbito apenas para reduzir os custos de auditoria. Um limite mais pequeno pode criar interfaces complicadas e deixar o requisito comercial sem resposta. Inversamente, incluir de imediato todas as empresas do grupo pode criar uma coordenação desnecessária. O limite certo é defensável, compreensível e operacionalmente gerível.

Registe a fundamentação e os fatores que levarão a reconsiderá-lo, como a aquisição de uma empresa, a mudança de infraestrutura ou o lançamento de um serviço substancialmente diferente. O âmbito deve continuar a ser uma decisão da gestão, e não um parágrafo esquecido.

Dar autoridade ao programa, não apenas um responsável

Nomeie um responsável pela implementação e um patrocinador da gestão que preste contas. Têm responsabilidades diferentes. O responsável pela implementação coordena o trabalho e garante a visibilidade; o patrocinador resolve prioridades, autoriza recursos e assegura que os objetivos de segurança se coadunam com as decisões de negócio.

A responsabilidade pelos controlos deve acompanhar a autoridade operacional. Os RH podem ser responsáveis pelos procedimentos relacionados com o emprego, as TI pela gestão de dispositivos, a engenharia pelas práticas de desenvolvimento e as compras podem coordenar a avaliação de fornecedores. O responsável de compliance não deve tornar-se nominalmente responsável por processos que não pode alterar.

Defina quem pode aceitar o risco residual e a que nível. Um responsável de serviço pode recomendar a aceitação de uma exposição operacional limitada, enquanto um risco que afete compromissos importantes com clientes pode exigir aprovação da administração. Registe a decisão, a fundamentação, as condições e a data de revisão.

A gestão também tem de proteger a capacidade de implementação. Atribuir trabalho sem criar espaço para ele gera atrasos previsíveis. Peça aos responsáveis o esforço necessário, as dependências e os compromissos; depois aprove um plano realista.

A revisão pela gestão é o momento em que a gestão avalia o sistema e toma decisões sobre melhoria, alterações e recursos. Uma ata assinada sem decisões significativas tem pouco valor prático. A revisão deve expor escolhas por resolver, e não apenas validar um painel verde.

Compreender os requisitos antes de comprar uma checklist

Os requisitos das cláusulas 4 a 10 da ISO/IEC 27001 formam o núcleo do sistema de gestão. Não podem ser excluídos quando se declara a conformidade. Os seus resultados práticos são distintos da implementação de controlos de segurança individuais.

O Anexo A da edição de 2022 contém 93 controlos de referência: 37 organizacionais, oito relativos a pessoas, 14 físicos e 34 tecnológicos. A aplicabilidade baseia-se no risco; não existe um número universal que todas as empresas devam implementar.

Determine os controlos necessários para o tratamento dos riscos e depois compare-os com o Anexo A para verificar se nenhum controlo necessário foi esquecido. Os controlos podem também resultar de requisitos contratuais, de outras fontes ou da vossa própria conceção. O Anexo A não substitui a avaliação de riscos nem é um catálogo exaustivo de todas as medidas de segurança possíveis.

A Declaração de Aplicabilidade (DdA, ou SoA na sigla inglesa) regista os controlos necessários, as razões para os incluir, o seu estado de implementação e a justificação para a exclusão de controlos do Anexo A. Mantenha rastreabilidade suficiente para explicar como essas decisões se relacionam com o tratamento de riscos e com outros requisitos.

A ISO 27002 fornece orientações sobre controlos de segurança da informação; a ISO 27001 fornece os requisitos certificáveis do sistema de gestão. Use as orientações para compreender as opções de implementação, mas adapte os procedimentos à vossa organização em vez de importar um modelo operacional que não conseguem manter.

Construir o tratamento de riscos antes de reunir evidências

Comece por um método de avaliação de riscos repetível. Defina como os riscos são identificados, como a probabilidade e as consequências são avaliadas, como os resultados são comparados e que critérios determinam a aceitabilidade. Uma interpretação coerente importa mais do que uma fórmula de pontuação complicada.

Descreva os riscos como cenários. «Risco de cloud» é demasiado vago para sustentar uma decisão. «Uma conta de administrador é comprometida e utilizada para exportar registos de clientes» identifica um evento, a informação afetada e uma consequência para o negócio.

Envolva pessoas que conhecem o serviço. Podem explicar as salvaguardas existentes, o acesso de suporte, as dependências de fornecedores, as limitações de recuperação e as soluções alternativas que uma biblioteca de riscos genérica pode não captar. Para uma estrutura de registo prática, consulte o nosso guia sobre um registo de riscos operacional.

Para cada risco significativo, registe o responsável, a avaliação, os controlos atuais, a decisão de tratamento, o resultado pretendido e a avaliação do risco residual. As abordagens de tratamento possíveis incluem reduzir a exposição, evitar uma atividade, partilhar aspetos do risco ou aceitá-lo segundo critérios definidos. Os seguros ou a subcontratação não eliminam todas as consequências nem todas as responsabilidades.

Traduza o tratamento em trabalho com responsáveis. «Melhorar a segurança dos acessos» não é um plano executável. Especifique os sistemas afetados, a alteração necessária, o responsável, os critérios de conclusão e a forma como a eficácia será avaliada.

Mantenha estes registos distintos:

Devem ser coerentes entre si sem se tornarem cópias uns dos outros. Se um tratamento depende da monitorização de fornecedores, mas o controlo correspondente está excluído sem explicação, resolva a incoerência antes de preparar a auditoria.

Reveja os riscos a intervalos planeados e quando ocorrem alterações significativas. Um novo prestador de suporte, uma recolha de dados alargada, um incidente ou uma alteração importante da arquitetura podem tornar obsoleta uma decisão anterior.

Integrar os controlos nas operações correntes

Uma política define expectativas; um procedimento explica como o trabalho é feito; os registos de funcionamento demonstram o que efetivamente aconteceu. A preparação para a certificação precisa dos três, quando aplicável.

Por exemplo, uma política de acessos deve estar ligada a um processo de entradas e saídas implementado, a alterações de acesso amostradas e a uma revisão de exceções. Um documento de política, por si só, deixa a maior parte dessa história por provar.

Construa o processo em torno das responsabilidades reais. Identifique quem pede o acesso, quem o aprova, quem o atribui, o que acontece quando a função de alguém muda e como as contas são removidas. Inclua contas de serviço e utilizadores externos quando afetem o âmbito.

Aplique o mesmo raciocínio a outros processos importantes:

• A avaliação de fornecedores deve ligar a criticidade do serviço, o acesso à informação, as expectativas contratuais, os resultados das revisões e as preocupações por resolver.
• A gestão de incidentes deve ligar os canais de reporte, as responsabilidades de resposta, a escalada, a recuperação e as lições aprendidas.
• As cópias de segurança e a recuperação devem ligar as necessidades do negócio, os sistemas protegidos, os procedimentos de reposição, os resultados dos testes e o trabalho de seguimento.
• A gestão de alterações deve ligar a aprovação, os testes, os registos de implementação, as alterações de emergência e as exceções.

Os controlos físicos e relativos a pessoas continuam a ser importantes numa organização baseada na cloud. O teletrabalho, a proteção de dispositivos, as conversas confidenciais, as alterações de vínculo laboral e a consciencialização não podem ser ignorados só porque os servidores são externos.

Defina a frequência dos controlos de acordo com o risco e as necessidades operacionais. Não copie para uma política a promessa de uma revisão trimestral, a menos que o responsável a consiga realizar e conservar os registos. Uma política que descreve um processo que ninguém segue cria uma lacuna evitável entre a intenção e a implementação.

Conceber evidências para inspeção, não para volume

Uma boa evidência responde a uma pergunta definida sobre um requisito ou controlo. Uma pasta enorme de capturas de ecrã não é, por natureza, mais sólida do que um conjunto mais pequeno e bem explicado de registos fiáveis.

Para cada controlo importante, especifique o sistema de origem, o responsável, o método de recolha, a cobertura, a frequência esperada e o revisor. Distinga as evidências de conceção das evidências de funcionamento. Uma configuração de identidades pode mostrar que a autenticação multifator está ativada; os registos de aprovação e as revisões de acessos demonstram outros aspetos da governação de acessos.

As evidências devem deixar claro o seu significado:

• Que serviço, sistema ou população abrangem?
• Quando foram produzidas e que período representam?
• São suficientemente completas para a pergunta em avaliação?
• Quem as reviu e que exceções foram identificadas?
• Que seguimento resultou dessas exceções?

Conserve também os resultados mal sucedidos. Um teste de reposição falhado, com investigação, correção e novo teste bem sucedido documentados, pode demonstrar que a monitorização e a melhoria funcionam. Apagar resultados inconvenientes prejudica a utilidade do registo.

Proteja as evidências como informação de pleno direito. As exportações podem conter dados de colaboradores, identificadores de clientes ou configurações sensíveis. Limite o acesso, minimize o conteúdo desnecessário e defina a conservação com base nas obrigações relevantes e nas necessidades do negócio. Organize um acesso controlado para os auditores, em vez de distribuir arquivos extensos de forma descuidada.

Usar a auditoria interna e a revisão pela gestão para testar a prontidão

A auditoria interna avalia se o SGSI cumpre os requisitos aplicáveis e se está efetivamente implementado e mantido. Deve abranger o sistema de gestão, e não apenas verificar parâmetros técnicos.

Planeie o âmbito, os critérios, os métodos e o reporte da auditoria. Selecione auditores competentes e preserve a objetividade e a imparcialidade. Uma pequena organização pode recorrer a apoio externo ou a soluções transversais adequadas, em vez de pedir a uma única pessoa que avalie todo o seu próprio trabalho.

Os testes de auditoria úteis seguem um registo ao longo do processo. Selecione a saída de um colaborador e verifique a notificação, a remoção de contas, o tratamento do equipamento e as exceções. Selecione um fornecedor e analise se a sua avaliação de riscos corresponde ao acesso que efetivamente tem. Selecione uma ação de tratamento e verifique se a conclusão declarada tem suporte operacional.

Registe as constatações com exatidão, incluindo o requisito, as evidências observadas e a lacuna. Não reduza a auditoria a uma percentagem de conclusão que oculta processos de gestão em falta.

A revisão pela gestão considera depois as entradas exigidas, incluindo o desempenho, os resultados de auditoria, as alterações, o estado da avaliação e do tratamento de riscos e as oportunidades de melhoria. Prepare um dossiê de decisão conciso, com os registos de suporte disponíveis. Explique onde a gestão tem de escolher entre correção, recursos adicionais, objetivos alterados ou aceitação de risco aprovada.

Nas não conformidades, separe a correção imediata da ação corretiva. Desativar uma conta esquecida corrige o problema imediato. Reparar o processo de notificação e verificar as saídas subsequentes trata a recorrência. Registe a causa, a ação, o responsável e a avaliação da eficácia.

Compreender a Fase 1, a Fase 2 e a decisão de certificação

A certificação inicial envolve normalmente duas fases de auditoria. Acorde com o organismo de certificação, com antecedência suficiente para planear adequadamente, as modalidades, os registos esperados e as expectativas de prontidão.

A Fase 1 analisa a prontidão, o âmbito e a documentação do sistema de gestão. Ajuda o organismo a compreender a organização e a avaliar a preparação para a Fase 2. Conte com uma análise atenta da relação entre âmbito, avaliação de riscos, tratamento, Declaração de Aplicabilidade e processos de gestão. Resolva as preocupações identificadas, em vez de tratar a Fase 1 como um passo administrativo de agendamento.

A Fase 2 avalia a implementação e a eficácia. Os auditores utilizam entrevistas, observação e registos amostrados para testar se o SGSI funciona como descrito. Os colaboradores devem conseguir explicar as suas responsabilidades reais, e não recitar respostas ensaiadas.

Mantenha os pedidos organizados durante a auditoria. Nomeie um coordenador, registe os pedidos, identifique o responsável certo e forneça as evidências relevantes com contexto. Se faltar alguma coisa, explique a situação com exatidão. Não crie registos retroativos que deem a entender, falsamente, que um processo ocorreu.

Uma não conformidade significa que um requisito não foi cumprido. As constatações maiores afetam a capacidade do sistema de gestão para atingir os resultados pretendidos; as menores não têm esse efeito. A classificação depende do contexto, pelo que não é possível atribuir antecipadamente uma classificação universal à falta de um único registo.

O organismo de certificação determina de forma independente as constatações, as respostas exigidas, as modalidades de verificação e a decisão de certificação. Confirme antecipadamente os seus prazos e requisitos de seguimento. A recomendação de um auditor não é, em si mesma, um certificado emitido, e constatações por resolver podem atrasar a decisão.

Após a certificação, um ciclo típico inclui auditorias de acompanhamento nos anos intermédios e uma recertificação antes de o certificado de três anos expirar. Confirme com o vosso organismo o programa de auditoria e as condições específicas. As auditorias de acompanhamento não são uma autorização para suspender o SGSI entre visitas.

Planear o calendário e o orçamento em função das dependências

A duração depende da maturidade, do âmbito, dos riscos por resolver, da disponibilidade de evidências, da capacidade interna e da agenda dos auditores. Não existe um período universal de evidências de funcionamento ISO 27001 que torne qualquer organização automaticamente pronta.

Pergunte ao organismo de certificação o que precisa de amostrar nas vossas circunstâncias. Um processo realizado mensalmente produz registos de forma diferente de um exercício anual. Não espere pela marcação da auditoria para descobrir que um controlo importante nunca foi executado.

Separe o trabalho que pode acelerar (recolha, coordenação, redação e preparação de revisões) do trabalho que exige implementação e funcionamento demonstrado. Execute em paralelo as tarefas independentes, mas preserve as dependências: uma Declaração de Aplicabilidade não pode ser finalizada de forma credível sem a fundamentação da seleção de controlos, e a eficácia não pode ser avaliada apenas com base numa política proposta.

Use marcos de prontidão em vez de uma única data final otimista:

Orçamente o esforço interno, a correção, as ferramentas, a formação, o eventual apoio de consultoria e a avaliação externa. Inclua as auditorias de acompanhamento, a recertificação e a manutenção contínua, e não apenas a fatura da primeira auditoria.

Peça aos organismos de certificação que expliquem os seus pressupostos sobre pessoal, instalações, atividades, complexidade e modalidades de auditoria. Compare o ciclo completo e os encargos de seguimento. Evite tratar um orçamento inicial baixo como o custo total de operar um SGSI certificado.

Exemplo prático: um serviço, um plano sustentável

Considere, a título ilustrativo, uma empresa de 30 pessoas que opera um serviço alojado de partilha de documentos. Suponha que já tem gestão de identidades, aprovações de implementação e cópias de segurança, mas que as revisões de fornecedores e os registos de revisão de acessos são inconsistentes. O seu potencial cliente quer garantias para o serviço alojado, incluindo o acesso de suporte.

A gestão inclui no âmbito o serviço e os processos de desenvolvimento, operações e suporte que o sustentam. Regista as interfaces com os RH e as TI partilhadas, em vez de excluir os seus efeitos na segurança. O CEO patrocina o programa; um responsável pela implementação coordena-o; os gestores operacionais são responsáveis pelos controlos.

A equipa identifica um cenário em que permissões de suporte excessivas expõem documentos de clientes. O tratamento inclui funções de suporte restritas, elevação temporária aprovada, revisões de acessos e monitorização adequada ao serviço. A Declaração de Aplicabilidade regista os controlos necessários e o estado de implementação.

O responsável pelos acessos recolhe então uma configuração de funções, registos de aprovação amostrados, uma revisão concluída e evidências de que as permissões excessivas detetadas nessa revisão foram removidas. Estes registos demonstram mais do que a mera existência de uma política de acessos.

Durante a auditoria interna, descobre-se que um prestador de serviços que já saiu ainda tem uma conta ativa. A equipa desativa-a, investiga a notificação dos RH para as TI que falhou, acrescenta um passo explícito de cessação para prestadores e verifica as saídas posteriores para avaliar a eficácia. A revisão pela gestão considera a constatação, os riscos remanescentes e os recursos necessários para as revisões contínuas.

Apenas para efeitos de planeamento orçamental, suponha que oito colaboradores dedicam cada um duas horas por semana durante doze semanas. Isso corresponde a 192 horas internas, antes da correção especializada e da participação na auditoria. Trata-se de um cálculo ilustrativo de capacidade, não de uma estimativa de mercado nem de uma promessa de certificação.

A lição é de gestão: atribuir o trabalho a pessoas com autoridade, reservar capacidade e fazer depender a prontidão das evidências. As salvaguardas técnicas existentes reduzem parte do trabalho de implementação, mas não substituem as decisões de risco, a auditoria interna nem a revisão pela gestão.

Automatizar o trabalho repetível sem abdicar do juízo

A automatização pode apoiar a atualização de inventários, a recolha de evidências, os lembretes, as verificações técnicas e o reporte. Dê prioridade ao trabalho recorrente com dados de origem fiáveis e um revisor claro, em vez de automatizar um processo pouco claro.

Uma verificação automática precisa de uma cobertura definida e de um tratamento de falhas. Se uma ligação deixar de recolher registos, distinga «nenhum problema detetado» de «sem dados atuais». Confirme que a fonte abrange os sistemas, contas ou localizações relevantes antes de confiar no resultado.

Mantenha explícito o juízo humano na aceitação de riscos, na aplicabilidade dos controlos, nas conclusões sobre evidências e nas decisões da gestão. Uma verificação de configuração pode mostrar que a cifragem está ativada; não estabelece que o acesso às chaves, a recuperação e os fluxos de dados excecionais são geridos de forma adequada.

Do mesmo modo, a automatização de fluxos de trabalho pode organizar os pedidos e as constatações da auditoria interna, mas não fornece competência nem independência de auditoria. Os resumos e mapeamentos gerados por IA devem continuar a ser rascunhos até que um revisor verifique as fontes e aprove as conclusões.

Meça tanto a eficiência como a eficácia: tempo gasto a preparar evidências, ações corretivas em atraso, cobertura incompleta, falhas repetidas e tempo necessário para resolver exceções importantes. O nosso guia sobre métricas do SGSI explica como tornar as medições úteis para as decisões da gestão.

Manter a responsabilidade ativa após a certificação

Antes de o certificado chegar, estabeleça o calendário de manutenção. As recomendações práticas incluem verificações regulares pelos responsáveis, revisões de riscos desencadeadas por alterações relevantes, avaliações de controlos planeadas, auditorias internas, revisões pela gestão e preparação para as avaliações externas. Escolha as frequências de acordo com o processo e o risco, em vez de tornar todas as atividades mensais.

Reatribua responsabilidades quando os colaboradores mudam de funções ou saem. Reveja o âmbito e a aplicabilidade dos controlos quando o negócio muda. Acompanhe as exceções recorrentes: remoções de acessos repetidamente tardias sugerem um problema de processo, mesmo que cada caso individual acabe por ser encerrado.

A Secani apoia este fluxo de trabalho ao ligar requisitos, controlos, evidências, responsáveis, tarefas e decisões de revisão num espaço de trabalho partilhado. Comece por um serviço representativo, modele os seus sistemas e dependências, associe as evidências existentes àquilo que comprovam e transforme as lacunas em tarefas atribuídas. Reveja as sugestões assistidas por IA face às respetivas fontes e preserve as aprovações humanas e o histórico de decisões. Isto ajuda a equipa a conservar o que aprende durante a certificação à medida que os sistemas mudam; a certificação continua a ser uma decisão do organismo independente.

Perguntas que alteram o plano de implementação

A ISO 27001 exige um teste de intrusão?

Não existe nenhuma cláusula universal da ISO 27001 que obrigue todas as organizações a realizar um teste de intrusão. Os testes necessários dependem do tratamento de riscos, dos controlos aplicáveis, das características do serviço e dos requisitos contratuais. Quando os testes são necessários, defina a cobertura, a correção e o novo teste, em vez de conservar apenas um relatório.

Devemos optar antes pelo SOC 2?

Pergunte o que os clientes exigem e que âmbito esperam. O SOC 2 produz um relatório de atestação; a ISO 27001 produz uma certificação do sistema de gestão. Algumas evidências de funcionamento podem ser reutilizáveis, mas nenhum dos dois se converte automaticamente no outro. Avalie os requisitos de cada um antes de se comprometer com ambos.

Precisamos de um consultor externo?

Não necessariamente. O apoio externo pode ajudar na interpretação, na capacidade ou em necessidades especializadas. Mantenha a responsabilidade interna e garanta que os procedimentos continuam utilizáveis depois de o trabalho terminar. A credencial de implementador ou de auditor de uma pessoa não certifica o seu empregador.

Começar com uma decisão e um rasto de evidências

Aprove uma carta de implementação breve que indique a necessidade comercial, o âmbito pretendido, o patrocinador, o responsável pela implementação, os responsáveis pelos controlos, a capacidade e os marcos de prontidão. Depois, pegue num serviço importante e acompanhe um controlo desde o requisito até ao tratamento de riscos, à implementação, às evidências e à revisão.

Esse primeiro rasto vai expor responsabilidades pouco claras e registos em falta antes que se multipliquem. Use a nossa checklist ISO 27001 para organizar o trabalho restante, mantendo distintos os requisitos do sistema de gestão e a aplicabilidade dos controlos.

Um SGSI duradouro torna as decisões de segurança verificáveis e repetíveis. A certificação reconhece o sistema dentro do seu âmbito; a gestão mantém-no em funcionamento depois de a equipa de auditoria partir.