Pular para o conteúdo principal
Ricardo EsperCISO · CYBER
Menu
LinkedIn →
Voltar para todos os artigos
Segurança da InformaçãoGovernançaMétricas

KPI e KRI: a diferença é o tempo

A diferença entre KPI e KRI em segurança da informação não é de formato, é de direção temporal: um mede desempenho passado, o outro antecipa exposição. Pares de indicadores por domínio, as três coisas que transformam número em indicador, a armadilha da métrica confortável, e a exigência da cláusula 9.1 da ISO 27001 e da 42001.

Barras de um gráfico onde a mais alta, em destaque, representa o indicador de risco

Existe uma pergunta que eu faço em toda avaliação de segurança e que raramente tem resposta boa: qual foi a última decisão que alguém tomou por causa de um número do seu painel?

Não "qual métrica vocês acompanham". Qual decisão mudou. Onde o orçamento foi realocado, qual projeto foi adiado, quem foi chamado para explicar.

Quando a resposta é o silêncio, a organização não tem indicadores. Tem relatório.

KPI e KRI não são a mesma coisa, e a diferença é o tempo

A confusão entre os dois é a origem de quase todo painel inútil. A distinção não é de formato — é de direção temporal.

KPI olha para trás. Mede o desempenho do que você já faz. "Fechamos 87% das vulnerabilidades críticas no prazo." É uma nota de prova.

KRI olha para frente. Mede exposição que está crescendo. "Temos 14 vulnerabilidades com exploração conhecida em aberto há mais de 30 dias." É um aviso.

Um diz como você foi. O outro diz o que vem.

O teste prático para separar: se o número piorar, isso é um problema agora ou um incidente depois? Se for um problema agora, é KPI. Se for um incidente depois, é KRI — e merece limiar, dono e gatilho.

Vale um exemplo de par, porque quase sempre eles andam juntos:

Domínio KPI (desempenho) KRI (exposição)
Identidade Conclusão da revisão de acesso privilegiado Contas privilegiadas sem MFA forte
Superfície externa Tempo de remediação de serviço exposto Ativos voltados à internet descobertos e desconhecidos
Vulnerabilidades Taxa de fechamento de críticas Vulnerabilidades com exploração conhecida em aberto
Endpoint Cobertura de EDR Endpoints sem proteção ativa
Resposta Tempo médio de contenção Alertas de alta severidade fora do SLA
Resiliência Sucesso no teste de restauração Falhas de restauração durante o teste

Repare no padrão: a coluna da esquerda é uma taxa, a da direita é uma contagem de coisas erradas neste momento. Taxa conforta. Contagem incomoda. É a contagem que move orçamento.

Três coisas que transformam número em indicador

A maioria dos painéis tem métrica demais e indicador de menos. O que separa um do outro:

Limiar declarado antes. Um número sem valor de referência não informa nada. "12 contas privilegiadas sem MFA" só vira indicador quando existe um limiar — zero, três, o que for — definido antes de o número aparecer. Limiar decidido depois do resultado é justificativa, não controle.

Dono nomeado. Pessoa, não área. "Infraestrutura" não responde por nada; alguém responde. Métrica sem dono é métrica que ninguém olha na segunda-feira.

Consequência combinada. O que acontece quando o limiar é rompido. Se a resposta for "a gente discute na próxima reunião", o limiar é decorativo. Consequência real é: escala para o comitê, trava o deploy, aciona plano de remediação com prazo.

Sem os três, você tem um gráfico. Com os três, você tem um controle.

A armadilha da métrica confortável

Toda área de segurança tende, sem má-fé, a medir o que sai bem.

Cobertura de EDR em 98% é um número agradável. Mas os 2% que faltam não são aleatórios — costumam ser exatamente os sistemas legados, os servidores que ninguém quer reiniciar, a máquina do diretor. O KPI diz 98%. O KRI, que seria "quais endpoints estão sem proteção e há quanto tempo", diz outra coisa inteiramente.

O mesmo vale para tempo médio de detecção. A média esconde a cauda, e o incidente que vai te machucar mora na cauda. Medir percentil 95 em vez de média muda a conversa, e é uma mudança que custa uma tarde de trabalho.

A pergunta de auditoria que expõe isso rápido: quais métricas vocês pararam de mostrar quando começaram a ficar ruins?

Onde a norma ajuda

Quem trabalha com ISO 27001 já tem a exigência na cláusula 9.1 — monitoramento, medição, análise e avaliação. Ela obriga a definir o que medir, os métodos, quando medir e quem avalia. Não é sugestão, é requisito auditável.

A 42001, para sistemas de IA, repete a mesma estrutura na mesma cláusula. E aí aparece uma dificuldade nova que vale antecipar: quase ninguém tem KRI de agente de IA. Quantos agentes existem no ambiente, quais têm credencial própria, quais alcançam sistema de produção, quantos foram autorizados formalmente. São perguntas que ninguém está medindo — e é exatamente onde a exposição está crescendo mais rápido.

Menos, e melhor

A tentação é montar um painel com 24 indicadores. A prática diz outra coisa.

Diretoria consome cinco a sete, no máximo, e precisa que cada um responda a uma pergunta de negócio. Nível operacional consome muito mais, e tudo bem — mas o que sobe não é a mesma coisa que o que a equipe olha.

Se eu tivesse que escolher poucos para um comitê, escolheria pela capacidade de mudar uma decisão:

  1. Vulnerabilidades com exploração conhecida em aberto, e há quanto tempo
  2. Ativos voltados à internet que ninguém sabia que existiam
  3. Contas privilegiadas sem MFA resistente a phishing
  4. Falhas de restauração no último teste de recuperação
  5. Percentil 95 do tempo de contenção
  6. Agentes e integrações automatizadas com acesso a produção, sem dono declarado

Nenhum deles é confortável. É esse o ponto.

O resumo

Indicador bom não é o que prova que a segurança vai bem. É o que antecipa onde ela vai falhar, cedo o suficiente para alguém fazer alguma coisa.

Se o seu painel nunca produziu uma conversa desconfortável na diretoria, ele não está medindo risco. Está medindo esforço.

E esforço, sozinho, nunca conteve incidente nenhum.