A avaliação de riscos é o ponto em que quase todos os projetos de ISO 27001 encalham, e também onde mais se nota se o sistema de gestão foi montado a sério ou apenas no papel. Muitas organizações investem semanas a preencher uma folha de cálculo enorme, com dezenas de ameaças teóricas e pontuações atribuídas a olho, e chegam à auditoria com um documento que ninguém usa e que não explica porque é que se escolheram uns controlos e se descartaram outros.
Neste artigo vemos o que é a avaliação de riscos segundo a ISO 27001, porque é que condiciona o resto do sistema, que método convém usar e como fazê-la passo a passo.
O que é a avaliação de riscos na ISO 27001?
A avaliação de riscos é o processo através do qual uma organização identifica os riscos que ameaçam a segurança da sua informação e determina a sua probabilidade e o seu impacto. Por outras palavras: reconhecer o que pode correr mal, com que probabilidade aconteceria e que consequências teria para a confidencialidade, a integridade e a disponibilidade da informação.
A cláusula 6.1.2 da ISO 27001 obriga a definir um processo de avaliação de riscos, aplicá-lo de forma coerente e conservar a informação documentada como evidência. A norma não a apresenta como uma tarefa pontual: exige repeti-la a intervalos planeados e sempre que ocorram alterações relevantes na organização ou no seu contexto.
Convém esclarecer três termos que muitas vezes se usam como sinónimos sem o serem. A análise de riscos é a fase em que se estimam a probabilidade e o impacto de cada risco. A avaliação de riscos é o processo completo, que inclui essa análise mais a comparação dos resultados com os critérios de aceitação para decidir que riscos são prioritários. Já o tratamento de riscos é o passo seguinte, em que se decide o que fazer com cada um.
Porque é que a avaliação de riscos é o ponto de partida do SGSI?
A ISO 27001 é uma norma baseada no risco. Isto significa que os controlos que uma empresa implementa não saem de uma lista padrão nem de imitar a concorrência, mas sim da sua própria exposição. Duas organizações do mesmo setor podem acabar com sistemas de controlo muito diferentes, precisamente porque os seus riscos são diferentes.
Essa lógica coloca a avaliação na base do sistema de gestão de segurança da informação (SGSI). Dos seus resultados depende que controlos do Anexo A vais aplicar e quais vais justificar por escrito que descartas. Sem uma avaliação sólida, essa decisão fica sem fundamento, e o auditor deteta-o de imediato.
Há ainda uma dependência prévia a ter presente: não se podem avaliar riscos sobre ativos que não se conhecem.
Abordagem qualitativa ou quantitativa: qual escolher?
A ISO 27001 não impõe um método concreto. Exige que seja coerente, reproduzível e que gere resultados comparáveis, mas deixa cada organização decidir como o aplica. Na prática existem duas grandes abordagens, e a maioria combina elementos de ambas.
- Abordagem qualitativa: avalia a probabilidade e o impacto em escalas descritivas (por exemplo, de 1 a 5, ou baixo/médio/alto) e cruza-os numa matriz de risco. É rápida de aplicar, fácil de comunicar à direção e suficiente para a maioria das PME.
- Abordagem quantitativa: atribui valores numéricos e monetários à probabilidade e ao impacto, apoiando-se em dados e fórmulas. Traz mais precisão e ajuda a justificar investimentos, mas exige um histórico fiável e mais tempo de trabalho.
Como fazer uma avaliação de riscos ISO 27001 passo a passo?
Embora a norma dê liberdade metodológica, as avaliações que funcionam seguem quase sempre a mesma sequência. Estes seis passos organizam o trabalho e evitam que fique a meio.
1. Inventaria os ativos de informação
Começa pelo que é preciso proteger. Percorre cada categoria (dados, hardware, software, serviços na cloud e pessoas com acesso) e cataloga-a dentro do âmbito do SGSI. Este passo apoia-se diretamente no inventário de ativos: se já o tens construído, boa parte do trabalho está feita. Se partes do zero, delimita primeiro o âmbito com clareza, porque é isso que te diz o que entra no inventário e o que fica de fora.
Cada ativo deveria ficar registado com um mínimo de informação útil para a análise posterior: o que é, quem é o seu proprietário e que nível de sensibilidade tem a informação que trata. É esse contexto que depois te permite estimar o impacto de um risco com critério, e não a olho.
O erro mais comum aqui é limitares-te ao hardware e deixar de fora o SaaS contratado por cada equipa, que é justamente por onde entra o risco que ninguém vigia. Este shadow IT não aparece sozinho: convém cruzar o inventário com as ferramentas que estão realmente a ser usadas e com as despesas recorrentes antes de o dares por fechado.
2. Identifica ameaças e vulnerabilidades
Para cada ativo, pergunta-te o que pode correr mal e que fraqueza o tornaria possível. Uma ameaça é o evento (roubo, encriptação por ransomware, erro humano, falha de um fornecedor) e a vulnerabilidade é a porta que deixa passar essa ameaça (um portátil sem encriptação, um software sem patches, um acesso que não foi revogado a tempo). Quase sempre são precisas as duas para que um risco se concretize, por isso convém ligar cada ameaça à vulnerabilidade concreta que a habilita.
Não é preciso inventar catálogos infinitos. Concentra-te nos cenários realistas para o teu tipo de organização e para a tua forma de trabalhar, e apoia-te nos incidentes que já viveste ou que são habituais no teu setor.
3. Analisa a probabilidade e o impacto
Aqui chega a análise de riscos propriamente dita. Para cada risco, pontua a probabilidade de ocorrer e o impacto que teria se ocorresse, usando a escala que definiste na tua metodologia. Lembra-te de que o impacto não é só económico: também pode ser reputacional, legal ou de continuidade do negócio.
A combinação das duas pontuações dá o nível de risco. Aplica o mesmo critério a todos os riscos para que os resultados sejam comparáveis entre si, que é precisamente o que a norma espera de um método coerente.
4. Prioriza os riscos com a matriz
Nenhuma equipa tem recursos infinitos, por isso é preciso decidir a que riscos dedicas tempo e dinheiro e quais podes deixar para segundo plano. Cruza probabilidade e impacto numa matriz de risco e confronta o resultado com os teus critérios de aceitação. Assim distingues os riscos que exigem ação imediata daqueles que caem dentro de um nível aceitável.
A matriz é, além disso, a forma mais clara de explicar essas prioridades à direção, porque traduz a análise num mapa visual onde se vê de relance onde está o crítico. É esse apoio que depois justifica o investimento em controlos e ajuda a que as decisões não dependam apenas do critério da equipa de IT.
5. Define o tratamento de cada risco
Para cada risco acima do limiar, decide o que vais fazer com ele (vemo-lo em detalhe na secção seguinte) e atribui um proprietário responsável por essa decisão.
Quando aplicas um controlo para o reduzir, permanece um risco residual: é o nível que continua a existir depois de implementada a medida, e que também tem de ser avaliado e aceite formalmente. Todas estas decisões ficam depois plasmadas na Declaração de Aplicabilidade, que liga cada risco aos controlos escolhidos para o tratar.
6. Documenta e revê a intervalos planeados
Tudo o que ficou para trás tem de deixar rasto. O auditor vai querer ver dois documentos: o relatório de avaliação de riscos, com os riscos identificados e as suas pontuações, e o plano de tratamento de riscos, com a opção escolhida e o responsável por cada um. Podes partir de um modelo para não começar do zero, mas adapta-o à tua realidade em vez de herdar riscos que não são teus.
E não a trates como um entregável de uso único. Fixa uma periodicidade de revisão e atualiza a avaliação sempre que mude algo relevante: um novo serviço, um incidente, uma reorganização.
As quatro opções de tratamento do risco
Depois de priorizados os riscos, a ISO 27001 contempla quatro formas de responder a cada um. Não são exclusivas: um mesmo risco pode ser em parte reduzido e aceite no que sobra.
- Reduzir: aplicar controlos de segurança que diminuam a probabilidade ou o impacto. É a opção mais frequente e a que se liga ao Anexo A.
- Aceitar: assumir o risco de forma consciente e documentada quando o seu nível está dentro do limiar ou quando o custo de o tratar supera o dano potencial.
- Transferir: passar o risco para um terceiro, por exemplo através de um seguro ou externalizando o serviço afetado.
- Evitar: eliminar a causa do risco deixando de realizar a atividade que o gera.
Exemplo prático: um registo de riscos ISO 27001
É assim que se veria um registo de riscos simplificado para uma empresa com uma equipa de IT reduzida e trabalho híbrido. As pontuações vão numa escala de 1 a 3 (1 = baixo, 3 = alto) e o nível de risco resulta da combinação de probabilidade e impacto.
| Risco | Probabilidade | Impacto | Nível | Tratamento |
|---|---|---|---|---|
| Um colaborador cai num phishing e roubam-lhe as credenciais | 3 | 3 | Alto | Reduzir — MFA e sensibilização |
| Software sem patches explorado por malware | 2 | 3 | Alto | Reduzir — política de patching centralizado |
| Portátil perdido ou roubado com dados sem encriptação | 2 | 2 | Médio | Reduzir — encriptação do disco e MDM com eliminação remota |
| Saída de um colaborador sem revogar os acessos | 2 | 3 | Alto | Reduzir — offboarding ligado ao RH |
| Falha de um fornecedor SaaS crítico | 1 | 3 | Médio | Transferir — SLA e backup próprio |
| Conta de redes sociais comprometida | 1 | 1 | Baixo | Aceitar — monitorizar, sem controlos adicionais |
Em quase todas as avaliações, os riscos que acabam no topo têm que ver com as pessoas e com os dispositivos, e muitos reduzem-se com controlos técnicos concretos como a encriptação, o patching, a gestão de acessos ou a eliminação remota de um equipamento perdido. Tê-los centralizados é o que transforma o registo de riscos numa ferramenta que reduz a exposição em vez de apenas a descrever.
Como é que o Factorial IT te ajuda a gerir o risco do teu SGSI?
Uma coisa é ter o risco identificado num registo, outra é reduzi-lo a sério. O Factorial IT atua sobre essa segunda parte, a do tratamento, porque reúne numa só plataforma as alavancas técnicas com que se mitigam os riscos que quase sempre acabam na parte alta da matriz.
Se revês o exemplo da tabela anterior, a maioria desses riscos trata-se a partir daqui:
- Equipamentos perdidos ou roubados: o MDM aplica a encriptação de forma centralizada e permite bloquear ou eliminar um dispositivo remotamente, de modo que um portátil extraviado deixa de ser uma fuga de dados.
- Software desatualizado: o controlo do parque permite saber que versões correm em cada equipamento e manter o patching em dia, a vulnerabilidade por detrás de boa parte dos incidentes por malware.
- Acessos que sobrevivem a uma saída: a gestão de acessos permite retirar permissões quando uma pessoa muda de função ou sai, fechando a porta aos acessos órfãos.
- Riscos que decides aceitar ou vigiar: ao teres o estado real de cada ativo à mão, rever um risco assumido e justificar essa decisão perante o auditor deixa de depender de uma folha de cálculo desatualizada.
