Métricas de SOC: MTTD, MTTR e os KPIs que mostram se a operação de segurança funciona

Quais são as principais métricas de SOC

Métricas de SOC são indicadores que medem a velocidade, a qualidade e a capacidade de um centro de operações de segurança. As principais são MTTD (tempo médio de detecção), MTTA (tempo médio de reconhecimento), MTTR (tempo médio de resposta), dwell time, taxa de falsos positivos e cobertura de detecção, que juntas mostram quanto tempo o atacante fica livre no ambiente.

Sem essas medidas, o SOC vira uma caixa preta: consome orçamento, gera relatórios de "alertas tratados" e ninguém sabe se a empresa está mais protegida. O problema é comum. No SANS SOC Survey 2025, 69% dos SOCs disseram ainda reportar métricas de forma manual ou majoritariamente manual, e quase metade afirmou que esse trabalho consome tempo demais.

Os números de mercado mostram por que medir tempo é a prioridade. O IBM Cost of a Data Breach 2026 registrou média de 183 dias para identificar e 64 dias para conter uma violação, 247 dias no total. Do outro lado, o CrowdStrike Global Threat Report 2026 mediu 29 minutos de tempo médio de breakout. A distância entre esses dois relógios é o que as métricas de SOC existem para encurtar.

Este guia traz as fórmulas, um exemplo de cálculo, benchmarks atualizados, os erros mais comuns e quais indicadores levar para cada público.

Leia também: O que é SOC: guia completo do centro de operações de segurança

A linha do tempo de um incidente: onde cada métrica começa e termina

Toda métrica de tempo do SOC é um recorte da mesma linha do tempo:

1. T0, comprometimento: o atacante obtém acesso inicial.
2. T1, primeiro evento registrado: um log ou telemetria captura a atividade.
3. T2, alerta gerado: o SIEM, EDR ou XDR dispara.
4. T3, reconhecimento: um analista (ou agente) assume o alerta.
5. T4, veredito: a investigação confirma o incidente.
6. T5, contenção: o host é isolado, a conta bloqueada, o acesso cortado.
7. T6, erradicação e correção: a causa raiz é removida e o ambiente volta ao normal.

Com essa régua, as definições deixam de ser ambíguas. O MTTD vai de T0 a T2 (ou T4, se a organização só conta detecção confirmada). O MTTA vai de T2 a T3. O MTTC vai de T4 a T5. O MTTR vai da detecção até a contenção ou até a resolução, e a organização precisa declarar qual dos dois está medindo.

MTTD: tempo médio de detecção

Fórmula: soma de (momento da detecção menos momento do comprometimento) de todos os incidentes do período, dividida pelo número de incidentes.

O MTTD é a métrica mais importante e a mais difícil de medir, porque o T0 só é conhecido depois da investigação. Por isso, calcule-o apenas sobre incidentes confirmados, com o comprometimento reconstituído pela análise forense.

O que o MTTD revela: a qualidade da cobertura de telemetria e das regras de detecção. MTTD alto quase sempre significa fonte de log faltando, regra mal calibrada ou alerta enterrado na fila.

Benchmark: o Mandiant M-Trends 2026 registrou dwell time mediano global de 14 dias em 2025, acima dos 11 dias de 2024. Em casos de espionagem, a mediana chegou a 122 dias.

MTTA: tempo médio de reconhecimento

Fórmula: soma de (momento em que o alerta foi assumido menos momento em que foi gerado), dividida pelo número de alertas.

O MTTA mede a fila. Se o SIEM detecta em segundos, mas o alerta espera quatro horas até alguém abrir, o ganho de detecção se perde. É a métrica que mais sofre com fadiga de alertas e com turnos descobertos, e deve ser medida por severidade: um alerta crítico com MTTA de uma hora é um problema; um informativo com MTTA de um dia pode ser aceitável.

Leia também: Fadiga de alertas no SOC: causas e como reduzir

MTTR: tempo médio de resposta (e a confusão com correção)

Fórmula: soma de (momento da contenção ou resolução menos momento da detecção), dividida pelo número de incidentes.

A sigla MTTR tem dois usos no mercado, e misturá-los distorce qualquer comparação:

• No SOC, MTTR costuma significar Mean Time to Respond, o tempo médio de resposta até conter o incidente.
• Na gestão de vulnerabilidades e de exposição, MTTR é Mean Time to Remediate, o Tempo Médio de Correção de uma falha, medido da descoberta até o fechamento validado.

Os dois se conectam. Um incidente contido em uma hora, mas cuja vulnerabilidade de entrada leva 90 dias para ser corrigida, continua aberto para o próximo atacante. O Verizon DBIR 2025 mostrou que apenas 54% das falhas em dispositivos de borda e VPN foram totalmente corrigidas, com mediana de 32 dias. Por isso, vale medir o MTTR de resposta no SOC e o Tempo Médio de Correção no programa de exposição, e cruzar os dois. Esse segundo indicador é tratado em métricas de um programa CTEM e em indicadores de gestão de vulnerabilidades.

Outras métricas de tempo

• MTTI (Mean Time to Investigate): do reconhecimento ao veredito. Mostra quanto esforço cada investigação consome.
• MTTC (Mean Time to Contain): do veredito à contenção. É a métrica que precisa conversar com o tempo de breakout do atacante.
• Dwell time: do comprometimento até a remoção do atacante. É o indicador de resultado que resume todos os outros.

Tabela de métricas de SOC: fórmula, o que mede e meta de referência

Uma referência útil para metas de tempo é a regra 1-10-60 difundida pela CrowdStrike: detectar em 1 minuto, investigar em 10 e conter em 60. Poucas operações a atingem, mas ela expõe a ordem de grandeza certa quando o breakout médio está em 29 minutos.

Exemplo prático: calculando MTTD e MTTR de um mês

Suponha que um SOC confirmou quatro incidentes em setembro:

• MTTD = (6 + 60 + 0,5 + 132) / 4 = 49,6 horas
• MTTR (detecção até contenção) = (2 + 8 + 0,5 + 18) / 4 = 7,1 horas
• Mediana do tempo de detecção = (6 + 60) / 2 = 33 horas

Dois aprendizados aparecem. Primeiro, a média é puxada por um único caso (D), e por isso vale reportar média e mediana. Segundo, o incidente D revela uma lacuna de detecção em contas de serviço, e o incidente B, uma falha de correção na VPN. As métricas não servem para enfeitar o relatório: apontam onde investir.

Métricas de qualidade e de capacidade

Tempo sem qualidade engana. Um SOC pode derrubar o MTTA fechando alertas sem investigar. Por isso, acompanhe também:

• Taxa de falso positivo por regra: no SANS Detection & Response Survey 2025, 73% dos respondentes relataram aumento de falsos positivos. Medir por regra mostra quais desligar ou ajustar.
• Taxa de verdadeiro positivo sobre escalados: se o N2 recebe muitos casos que não eram incidentes, a triagem precisa de ajuste.
• Incidentes reabertos: indicam contenção incompleta.
• Cobertura de fontes de log: percentual de ativos críticos enviando telemetria ao SIEM.
• Retenção e rotatividade de analistas: o SANS SOC Survey 2025 apontou que 62% dos profissionais de SOC acham que a organização não faz o suficiente para reter talentos. Rotatividade alta derruba todas as outras métricas.

Leia também: KPIs de segurança cibernética: o que medir e como reportar

Quais métricas levar para cada público

Para o conselho, traduzir tempo em impacto ajuda. O IBM Cost of a Data Breach 2026 mostrou que violações com ciclo de vida acima de 200 dias custaram em média US$ 5,65 milhões, contra US$ 4,32 milhões abaixo desse limite. No Brasil, o custo médio de uma violação foi de R$ 7,19 milhões na edição de 2025.

Métricas exigidas pelo contexto regulatório brasileiro

Algumas métricas deixaram de ser apenas boas práticas:

• Tempo até a notificação à ANPD: a Resolução CD/ANPD nº 15/2024 dá três dias úteis, contados do conhecimento de que o incidente afetou dados pessoais. Medir o tempo entre detecção e decisão de notificar evita perder o prazo.
• Registro de incidentes: a mesma resolução exige manter o registro de todos os incidentes por cinco anos, o que pressupõe métricas consistentes ao longo do tempo.
• Instituições financeiras: a Resolução CMN nº 4.893/2021, atualizada pela CMN nº 5.274/2025, exige relatório anual sobre o plano de ação e de resposta a incidentes. MTTD, MTTR e cobertura de detecção são a base natural desse relatório.

Erros comuns ao medir um SOC

1. Contar alertas tratados como produtividade. Volume alto de alertas é sintoma, não conquista.
2. Misturar MTTR de resposta com Tempo Médio de Correção sem declarar qual é qual.
3. Reportar só a média. Um incidente longo distorce tudo; use média e mediana.
4. Medir sem carimbo de tempo confiável. Se o analista registra o horário à mão, o dado não vale.
5. Ignorar incidentes descobertos por terceiros. Eles são exatamente os que o SOC não viu, e precisam entrar na taxa de detecção interna.
6. Não revisar metas. A régua tem de acompanhar a velocidade do atacante.

Como montar um programa de métricas em 8 passos

1. Defina a linha do tempo oficial do incidente (T0 a T6) e documente.
2. Garanta carimbos de tempo automáticos no SIEM, no SOAR e no ITSM.
3. Padronize a classificação de severidade e de veredito.
4. Escolha de 6 a 10 métricas, não 40.
5. Publique média, mediana e percentil 90 para métricas de tempo.
6. Separe painéis por público.
7. Revise mensalmente regras com mais falsos positivos e lacunas de cobertura.
8. Cruze os indicadores do SOC com os do programa de exposição.

Como a IA agêntica muda as métricas do SOC

Quando um agente assume triagem e investigação, surgem duas mudanças. A primeira é que MTTA e MTTI deixam de depender do tamanho da fila. A segunda é que a medição fica confiável, porque cada passo é registrado.

No EcoTrust Agentic SOC, que opera sobre o SIEM, EDR e XDR do cliente, a observabilidade do agente registra o contexto consultado, o plano produzido, cada passo executado e seu resultado, e quem aprovou o quê e quando. Isso gera carimbos de tempo por etapa sem digitação manual, e a trilha pode ser exportada como evidência de auditoria. A contenção continua dependendo de aprovação humana, então o MTTC passa a refletir o tempo de decisão, não o de coleta de informações. O ganho de maturidade é acompanhado por um indicador próprio, o Agent Work Share, que mostra quanto da operação o agente conduz.

A realimentação encaminha a exposição encontrada durante o incidente ao Flow, onde vive o Tempo Médio de Correção, e o AutoPatch registra quando a correção foi aplicada e validada. Assim, o MTTR do SOC e o Tempo Médio de Correção da exposição passam a ser lidos lado a lado.

Perguntas Frequentes

Qual a diferença entre MTTD e MTTR?

O MTTD mede quanto tempo o SOC leva para perceber que um incidente começou, do comprometimento até a detecção. O MTTR mede quanto tempo leva para responder depois de detectar, até conter ou resolver. O primeiro avalia a qualidade da detecção; o segundo, a velocidade e a coordenação da resposta. Os dois somados aproximam o dwell time.

Qual é um bom MTTD para um SOC?

Não existe número universal, mas a referência de mercado é o dwell time mediano de 14 dias do Mandiant M-Trends 2026. SOCs maduros buscam detectar em horas os incidentes de alta severidade. Mais útil que perseguir um número é acompanhar a tendência mês a mês e investigar cada incidente que demorou mais que a mediana.

Como calcular o MTTR de incidentes de segurança?

Some, para cada incidente do período, o intervalo entre a detecção e a contenção (ou a resolução, se for esse o critério adotado) e divida pelo número de incidentes. Declare o ponto final escolhido, use carimbos de tempo automáticos e publique também a mediana, para que um único incidente longo não distorça o resultado.

O que é dwell time?

Dwell time é o tempo que um atacante permanece no ambiente, do comprometimento inicial até ser detectado e removido. É a métrica de resultado que resume detecção e resposta. O Mandiant M-Trends 2026 registrou mediana global de 14 dias em 2025, com casos de espionagem chegando a 122 dias.

Quais KPIs de SOC apresentar para a diretoria?

Para a diretoria, prefira poucas métricas com tendência: dwell time, número de incidentes materiais, tempo até notificação regulatória e taxa de detecção interna. Sempre que possível, traduza tempo em impacto financeiro, como o custo maior das violações que passam de 200 dias apontado pelo IBM Cost of a Data Breach 2026.

Conclusão: medir tempo é medir risco

Métricas de SOC só têm valor quando respondem a uma pergunta de negócio: quanto tempo o atacante tem dentro da empresa e o que está sendo feito para reduzir esse tempo. MTTD, MTTA, MTTR e dwell time formam o núcleo; taxa de falso positivo, cobertura de detecção e retenção de analistas explicam por que os tempos sobem ou descem.

Comece com poucas métricas, bem definidas e medidas automaticamente, publique média e mediana, e conecte o tempo de resposta do SOC ao Tempo Médio de Correção da exposição. É essa ligação que transforma relatórios de alertas em redução de risco comprovada.

---

Referências

• IBM Security, "Cost of a Data Breach Report 2026", 2026. ibm.com/reports/data-breach
• IBM Security, "Cost of a Data Breach Report 2025", 2025. ibm.com/reports/data-breach
• Mandiant (Google Cloud), "M-Trends 2026", 2026. cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
• CrowdStrike, "2026 Global Threat Report", 2026. crowdstrike.com/global-threat-report
• Verizon, "2025 Data Breach Investigations Report", 2025. verizon.com/business/resources/reports/dbir
• SANS Institute, "SANS 2025 SOC Survey", 2025. sans.org/white-papers/sans-2025-soc-survey
• SANS Institute, "2025 Detection and Response Survey", 2025. sans.org
• ANPD, "Resolução CD/ANPD nº 15, de 24 de abril de 2024", 2024. gov.br/anpd
• Conselho Monetário Nacional, "Resolução CMN nº 4.893/2021" e "Resolução CMN nº 5.274/2025". bcb.gov.br