Como escolher SOC/MDR parece simples até o dia em que o “monitoramento 24×7” vira um e-mail genérico às 3h da manhã, com um print do dashboard e zero orientação do que fazer.
Quem decide SOC/MDR não quer slide bonito. Quer previsibilidade, resposta e evidência para diretoria. Quer reduzir risco de verdade. E quer evitar três clássicos: “SLA de enfeite”, “alerta sem ação” e “relatório que não conversa com o negócio”.
Resumo rápido
Como escolher SOC/MDR: perguntas que evitam armadilhas começa checando três coisas: SLA real (tempo até alguém agir), capacidade de resposta (contenção e orientação prática) e governança (playbooks + relatórios executivos). Um bom SOC/MDR reduz ruído, acelera detecção e encurta o tempo até contenção, mas só se houver processo, responsabilidades claras e evidências mensais de resultado. Checklist rápido: (1) SLAs por severidade e canal de acionamento, (2) playbooks de incidentes críticos, (3) relatórios para C-level com risco e impacto, (4) trilha de auditoria e lições aprendidas, (5) integração com seu stack e com o time interno.
O que está realmente em jogo quando se compra SOC/MDR
A compra de SOC/MDR costuma acontecer depois de uma dor. Às vezes é um incidente. Às vezes é auditoria. Às vezes é a diretoria perguntando “e se der ruim amanhã?”.
No Brasil, o “dar ruim” virou caro. O custo médio de uma violação de dados no país chegou a R$ 7,19 milhões, segundo a IBM.
E ransomware, quando pega operação de verdade, também dói no caixa. Um relatório anual brasileiro cita custo médio acima de R$ 7 milhões por ataque em 2024.
Tem mais: se o incidente envolver dados pessoais, o relógio regulatório também corre. A ANPD estabeleceu prazo de 3 dias úteis para comunicação de incidente, conforme seu regulamento.
Por isso, “comprar SOC/MDR” é, na prática, comprar capacidade de decisão sob pressão. E decisão boa exige duas coisas: contexto e tempo.
O erro nº 1: confundir “monitorar” com “responder”
Monitorar é ver fumaça. Responder é apagar o fogo e impedir que vire incêndio.
Tem fornecedor que vende SOC/MDR como se fosse “alerta premium”. Ele detecta, avisa e some. Isso é terceirização de ansiedade, não de risco.
Um SOC/MDR decente faz triagem, investiga, recomenda ação e ajuda a conter. Se a proposta não fala claramente de resposta, já acende uma luz.
Quando a coisa aperta, o decisor não quer um PDF. Quer alguém dizendo:
- O que aconteceu,
- Qual o impacto provável,
- O que fazer agora,
- O que fazer depois para não repetir.
Se isso não está contratualmente amarrado, a chance de frustração é alta.
O erro nº 2: comprar SLA “bonito”, sem definir o que ele mede
SLA é uma palavra perigosa porque parece objetiva. Só que muita proposta usa SLA para medir “tempo de recebimento do alerta”, “tempo de abertura de ticket” ou “tempo de primeira resposta automática”.
Na prática, isso pode significar “alguém clicou em ‘ack’”. E você continua sozinho.
O SLA que importa é o SLA até ação humana qualificada. E ele precisa ser quebrado por severidade.
Exemplo de pergunta direta (e meio desconfortável, do jeito certo):
“Em um incidente crítico, qual é o tempo máximo até um analista iniciar investigação e qual é o tempo máximo até orientar contenção?”
Se a resposta vier vaga, com “depende”, “melhor esforço” ou “nossa plataforma”, é sinal de risco.
Como escolher SOC/MDR: perguntas que evitam armadilhas no SLA real
Antes de falar de ferramenta, fale de tempo e responsabilidade. O checklist abaixo dá tração.
Perguntas de SLA e acionamento:
- Quais são os SLAs por severidade (crítico/alto/médio/baixo)?
- O SLA mede o quê exatamente (triagem, investigação, contenção, comunicação)?
- Quais canais de acionamento existem (telefone, Teams, WhatsApp corporativo, portal)?
- Existe “war room” em incidente crítico? Quem convoca?
- Há cobertura 24×7 real, com analistas, ou só plantão de “escalação”?
- Como são tratados eventos fora do escopo? Viram “informativo” e pronto?
Se o fornecedor não tolera esse tipo de pergunta, melhor descobrir agora.
O erro nº 3: aceitar “playbook genérico” como se fosse plano de resposta
Playbook não é um arquivo bonito no SharePoint. É um fluxo que roda sob estresse.
Um bom SOC/MDR opera playbooks com gatilhos claros, decisões pré-aprovadas e responsáveis definidos. Ele também adapta playbooks ao seu ambiente, não ao “modelo de cliente”.
Aqui entra uma diferença prática: SOC/MDR maduro não inventa ação no meio do caos. Ele executa o que foi acordado antes.
O mínimo que faz sentido para decisor:
- ransomware,
- comprometimento de credenciais,
- e-mail malicioso/BEC,
- movimentação lateral,
- exfiltração de dados,
- acesso remoto suspeito (VPN/RDP).
A Sophos, por exemplo, publica análises de resposta a incidentes e tendências de adversários com base em casos reais, reforçando como credenciais e vetores comuns aparecem de forma recorrente em ataques.
Não basta “ter playbook”, ele precisa estar vivo, testado e com autoridade para agir.
Perguntas que expõem se o playbook é de verdade
Faça o fornecedor “simular” sem simular demais.
- “Se detectarem ransomware em estágio inicial, qual é o primeiro comando/ação recomendada?”
- “Quem aprova isolamento de máquina crítica? Existe procedimento para exceções?”
- “Como vocês lidam com falso positivo que parece crítico? Quem decide encerrar?”
- “Vocês entregam lições aprendidas pós-incidente? Em quanto tempo?”
- “Quais métricas de eficácia vocês acompanham: MTTD, MTTR, tempo até contenção?”
Se a resposta for só ferramenta, está faltando operação.
Benefícios do SOC/MDR que o CFO entende (sem precisar “virar técnico”)
“Benefícios do SOC/MDR” não é poesia, é efeito em risco, tempo e custo.
Três benefícios que costumam ficar claros rápido para a diretoria:
- Menos tempo de exposição: reduzir o tempo entre intrusão e detecção diminui o estrago.
- Menos tempo até contenção: crise curta custa menos, inclusive em reputação.
- Mais evidência: auditoria, seguradora, conselho e jurídico querem trilha e fatos.
E tem um benefício subestimado: reduzir o ruído operacional do time interno. Quando o SOC/MDR filtra, contextualiza e orienta, TI e segurança param de correr atrás de fantasma.
Dados de ransomware também mostram um ponto: a recuperação ainda pode levar semanas ou meses, mesmo quando há melhora em índices globais. Um levantamento da Sophos sobre ransomware em 2025 discute tendências de recuperação e impacto em organizações.
O decisor não precisa decorar números. Ele precisa entender que tempo é dinheiro, e que resposta é o que encurta esse tempo.
O “mapa da armadilha”: onde propostas de SOC/MDR costumam esconder pegadinhas
A pegadinha raramente está na capa. Ela vive no escopo, nas exclusões e na linguagem elástica.
Pontos clássicos para ler com lupa:
- “Melhor esforço” em incidentes críticos.
- Exclusão de cloud, AD, e-mail, endpoints específicos.
- Sem compromisso de resposta, só notificação.
- Relatórios “sob demanda” (tradução: quando der).
- Sem definição de severidade e critérios.
- “Integração” que vira projeto eterno.
Se você quiser ser direto: peça a matriz RACI do serviço. Quem é Responsável, Aprovador, Consultado e Informado em cada tipo de incidente. Essa simples tabela costuma separar marketing de operação.
Checklist de compra: o que pedir por escrito (para não depender de promessa)
Este é o trecho para imprimir mentalmente.
1) SLA real, por severidade, com definição operacional
Peça o SLA em termos de ação humana:
- tempo até triagem,
- tempo até investigação iniciar,
- tempo até orientação de contenção,
- tempo até comunicação executiva em crítico.
E exija definição do que é “crítico”. Sem isso, tudo vira “médio” quando convém.
2) Capacidade de resposta e escalonamento
Perguntas que fecham o cerco:
- O SOC/MDR pode orientar contenção e erradicação?
- Existe equipe de resposta a incidentes (IR) disponível quando o caso explode?
- Como o escalonamento funciona, na prática?
A Sophos tem serviços específicos de Incident Response e também MDR, e isso ajuda a entender a diferença entre “monitorar” e “responder” como disciplinas distintas.
3) Playbooks por cenário e exercícios
Peça:
- lista de playbooks incluídos,
- o que é customizável,
- como vocês testam (tabletop, simulação, revisão trimestral).
4) Relatórios executivos que prestam
Relatório bom não é longo. É acionável.
Ele precisa trazer:
- risco por unidade/processo,
- tendências (mês contra mês),
- top causas raiz,
- backlog de recomendações,
- e uma leitura “e se continuar assim, o que acontece?”.
5) Métricas que medem resultado, não vaidade
No mínimo:
- MTTD e MTTR,
- tempo até contenção,
- taxa de falso positivo,
- eventos por severidade,
- tempo de resposta por canal.
6) Evidência, auditoria e trilha
Se sua empresa tem LGPD no radar, isso vira essencial.
A ANPD tem diretrizes e prazos formais sobre comunicação de incidentes, e evidência organizada faz diferença quando o jurídico entra na sala.
A parte “chata” que salva: escopo, integrações e limites
Agora vem o ponto que muita gente pula: onde o SOC/MDR enxerga.
O SOC/MDR só é bom naquilo que ele observa. Então, antes da assinatura, defina:
- quais fontes de log entram (cloud, firewall, EDR, e-mail, AD, VPN),
- quais ambientes são críticos (filiais, OT, datacenter, SaaS),
- quais ativos são “intocáveis” (onde isolamento exige regra especial).
Se a sua operação usa muito Microsoft 365, por exemplo, peça exemplos de detecções e respostas para:
- regras de inbox suspeitas,
- login impossível,
- consent grants maliciosos,
- BEC.
E peça evidência: “mostra um relatório real (anonimizado)”.
Onde a VIVA entra nessa história (sem papo de “somos os melhores”)
O time da VIVA posiciona SOC/MDR como operação, não como vitrine.
Para quem está em processo de decisão, o caminho mais racional é começar pelo cenário real da empresa, antes de discutir “qual stack”. Isso reduz compra errada e acelera definição de playbooks e SLAs.
Dois links que você precisa ver:
E, para decisor, faz sentido ir direto ao diagnóstico que tira o “achismo” do caminho:
Solicite seu Perfil de Ameaças e saiba exatamente onde você está vulnerável.
Perguntas frequentes
SIEM e XDR são tecnologias e arquiteturas. MDR é serviço gerenciado com foco em detecção e resposta. SOC é o modelo operacional (pode ser interno, terceirizado ou híbrido). Na compra, o decisivo é: quem investiga e quem responde, com SLA e playbooks.
Não. Pode significar automação + plantão de escalação. Por isso, peça “cobertura humana” por turno e o SLA até investigação. Sem isso, 24×7 vira marketing.
Sim, e é comum. O ponto é definir bem o que fica com a empresa (decisão de negócio) e o que fica com o provedor (investigação, recomendação, contenção guiada, evidência). O erro é empurrar tudo para o time interno sem capacidade.
Não substitui. SOC/MDR reduz a chance de virar crise e acelera o começo da resposta. Mas incidentes grandes podem exigir resposta a incidentes dedicada, forense e coordenação estendida. A própria Sophos separa as ofertas de MDR e IR, o que ajuda a entender essa diferença.
Ele precisa conversar com risco e impacto. Se só tiver volume de alertas e gráficos bonitos, ele é fraco. Peça tendências, causas raiz, recomendações priorizadas e evidência do que foi contido.
Muda a pressão por prazo, critérios e documentação. A ANPD estabeleceu prazo de 3 dias úteis para comunicação do incidente, salvo hipóteses específicas, e isso exige governança e evidência desde o primeiro dia.
Fechamento: a compra certa é a que aguenta a madrugada
Se o decisor quer evitar armadilhas, a régua não é “quantas integrações tem”. É: “quando der ruim, quem faz o quê, em quanto tempo, com qual evidência”.
Se você fizer as perguntas de SLA real, resposta, playbooks e relatório executivo, metade das propostas cai sozinha. A outra metade vira shortlist séria.
E se a intenção é começar pelo que está exposto hoje, o CTA é simples: Solicite seu Perfil de Ameaças e saiba exatamente onde você está vulnerável. Porque, no fim, Como escolher SOC/MDR é escolher quem vai manter a sua operação de pé quando a internet resolver testar a sua paciência.
Deixe um comentário