Quais registros de um SOC demonstram monitoramento contínuo de segurança?

O monitoramento contínuo de segurança pode ser demonstrado por um conjunto de registros operacionais, como inventário de fontes, catálogo de casos de uso, alertas investigados, tickets, linhas do tempo de incidentes, ações executadas, métricas e históricos de melhoria.

Nenhum desses artefatos, isoladamente, comprova que o controle funciona. A avaliação precisa relacionar cobertura, detecção, investigação, resposta e acompanhamento das lacunas identificadas.

Esses registros podem apoiar auditorias, avaliações de clientes e processos internos de governança. No entanto, um SOC não certifica a instituição nem garante conformidade regulatória. A responsabilidade por políticas, decisões, riscos, comunicação ao regulador e validação da suficiência dos controles continua com a própria organização.

Para entender como essas capacidades se conectam às exigências regulatórias, veja também: como um SOC terceirizado apoia os requisitos de segurança do Banco Central.

O que significa demonstrar monitoramento contínuo?

Demonstrar monitoramento contínuo não significa apenas apresentar um contrato de SOC, uma ferramenta SIEM ou um relatório mensal. É preciso mostrar que os ativos e eventos relevantes estão sendo observados, que os alertas são investigados, que as ocorrências recebem tratamento e que as lacunas conhecidas possuem responsáveis e planos de evolução.

Na prática, a demonstração do controle depende de uma sequência verificável:

1. Os ativos, sistemas e riscos relevantes foram identificados.
2. As fontes de dados necessárias foram conectadas e permanecem disponíveis.
3. Existem casos de uso de detecção relacionados aos riscos priorizados.
4. Os alertas gerados passam por triagem e investigação.
5. As decisões e ações são registradas.
6. Os incidentes são escalados de acordo com critérios definidos.
7. As lacunas encontradas geram ações corretivas ou melhorias.
8. A instituição acompanha a evolução da capacidade ao longo do tempo.

Essa cadeia é mais relevante do que o volume de alertas ou a quantidade de ferramentas implantadas. Uma operação pode processar milhares de eventos e ainda não ter cobertura adequada sobre os riscos mais importantes para o negócio.

Quais registros o SOC precisa manter?

Os registros necessários variam conforme o ambiente, os riscos, os contratos e as obrigações aplicáveis. Ainda assim, uma operação madura costuma manter um conjunto mínimo de artefatos para explicar o que é monitorado, como as ocorrências são tratadas e quais pontos precisam evoluir.

Inventário de fontes monitoradas

O inventário de fontes mostra quais ambientes fornecem dados para a operação de segurança. Ele pode incluir ferramentas de identidade, endpoints, firewalls, aplicações, serviços em nuvem, bancos de dados, componentes de rede e soluções utilizadas em processos críticos.

O inventário deve permitir responder perguntas como:

• Quais ativos críticos enviam eventos para monitoramento?
• Quais fontes estão ativas, indisponíveis ou parcialmente integradas?
• Existe diferença entre o inventário de ativos e o escopo monitorado?
• Quem é responsável por cada fonte?
• Como falhas de coleta ou interrupções são identificadas?
• Há fontes críticas ainda não integradas?

Uma integração registrada como ativa não prova que os dados são suficientes. Também é necessário verificar qualidade, integridade, sincronização de horário, retenção e utilidade dos eventos para investigação.

Catálogo de casos de uso

O catálogo de casos de uso conecta os dados monitorados aos riscos que a organização pretende detectar. Ele deve registrar, no mínimo, o objetivo da detecção, as fontes utilizadas, a criticidade, a lógica aplicada, o procedimento de investigação e o responsável pela manutenção.

Um caso de uso pode existir tecnicamente e ainda ser pouco efetivo. Isso acontece quando a regra não utiliza as fontes adequadas, produz excesso de falsos positivos, deixa de acompanhar mudanças no ambiente ou não possui um procedimento claro para investigação.

Por isso, além de listar as regras existentes, o catálogo deve indicar:

• Risco ou comportamento monitorado.
• Fontes necessárias para a detecção.
• Severidade e critérios de priorização.
• Procedimento de investigação.
• Condições para escalonamento.
• Data da última revisão.
• Lacunas ou dependências conhecidas.

Alertas, tickets e investigações

Alertas e tickets mostram como a operação trata as ocorrências identificadas. Para serem úteis, esses registros precisam apresentar contexto suficiente para reconstruir a análise realizada.

Um ticket bem estruturado normalmente registra:

• Data e horário da detecção.
• Fonte ou sistema envolvido.
• Usuário, ativo ou identidade relacionada.
• Criticidade inicial e criticidade após a investigação.
• Dados consultados pelo analista.
• Hipóteses consideradas.
• Conclusão da análise.
• Decisão tomada.
• Ações realizadas ou recomendadas.
• Responsáveis e áreas acionadas.
• Motivo do encerramento.

O simples registro de que o alerta foi “analisado” ou classificado como falso positivo não é suficiente para explicar o raciocínio aplicado. Quanto maior a criticidade, maior deve ser a capacidade de reconstruir a investigação e as decisões tomadas.

Linha do tempo dos incidentes

A linha do tempo organiza os principais acontecimentos de um incidente, desde o primeiro evento identificado até a contenção, recuperação e encerramento. Ela ajuda a entender quanto tempo a organização levou para detectar o problema, tomar decisões e executar ações.

Uma linha do tempo útil diferencia:

• Momento em que o evento ocorreu.
• Momento em que o evento foi registrado.
• Momento em que o alerta foi gerado.
• Início da triagem e da investigação.
• Escalonamento para as áreas responsáveis.
• Decisões de contenção.
• Ações executadas.
• Recuperação dos serviços.
• Encerramento e revisão posterior.

Essa distinção evita interpretar o tempo de resposta apenas pela perspectiva do SOC. Em muitos casos, a execução de bloqueios, mudanças emergenciais, comunicações ou decisões de negócio depende de outras áreas da instituição.

Por que o relatório mensal não é suficiente?

Um relatório mensal isolado não demonstra que o controle funciona. Ele apresenta uma consolidação da operação, mas não substitui os registros detalhados que sustentam os indicadores exibidos.

Um relatório pode informar que determinada quantidade de alertas foi analisada. No entanto, essa informação não explica:

• Se os ativos críticos estavam cobertos.
• Se houve perda de eventos durante o período.
• Se os casos de uso estavam atualizados.
• Como os alertas mais críticos foram investigados.
• Quais decisões foram tomadas.
• Quais riscos permaneceram sem cobertura.
• Quais ações de melhoria foram priorizadas.

O relatório gerencial deve ser entendido como uma camada de consolidação. Abaixo dele precisam existir registros operacionais capazes de explicar os números, as ocorrências, as decisões e as limitações da operação.

Como relacionar alerta, investigação e resposta?

A rastreabilidade entre alerta, investigação e resposta é um dos sinais mais relevantes de maturidade operacional. O objetivo é permitir que uma ocorrência seja acompanhada desde a geração do alerta até a decisão final.

Uma cadeia mínima pode seguir esta estrutura:

1. Evento: o ambiente gera um registro relacionado a uma atividade.
2. Detecção: uma regra, correlação ou análise identifica um comportamento relevante.
3. Alerta: a ocorrência recebe contexto inicial e prioridade.
4. Investigação: o analista consulta dados complementares e testa hipóteses.
5. Classificação: a ocorrência é confirmada, descartada ou mantida sob observação.
6. Escalonamento: as áreas responsáveis são acionadas conforme a severidade.
7. Ação: medidas de contenção, bloqueio, correção ou recuperação são executadas.
8. Encerramento: a conclusão e os motivos da decisão são registrados.
9. Melhoria: aprendizados geram ajustes em regras, processos ou arquitetura.

Quando essa sequência não pode ser reconstruída, a instituição pode ter dificuldade para explicar como o controle opera, mesmo que possua ferramentas e equipes dedicadas.

Quais métricas ajudam a acompanhar o monitoramento?

As métricas devem ser interpretadas em conjunto. Reduzir o tempo médio de resposta, por exemplo, não representa necessariamente uma melhoria se os alertas mais complexos estiverem sendo encerrados sem investigação suficiente.

Entre os indicadores que podem apoiar o acompanhamento estão:

• Percentual de ativos críticos com fontes integradas.
• Disponibilidade e continuidade da coleta de eventos.
• Quantidade de casos de uso ativos e revisados.
• Tempo entre geração, detecção, triagem e escalonamento.
• Alertas por severidade e tipo de ocorrência.
• Recorrência de incidentes ou comportamentos.
• Casos de uso com excesso de falsos positivos.
• Fontes com falhas ou baixa qualidade de dados.
• Lacunas abertas, vencidas e corrigidas.
• Melhorias executadas após incidentes ou revisões.

O objetivo não deve ser produzir o maior número possível de indicadores, mas selecionar métricas capazes de orientar decisões sobre risco, cobertura e evolução operacional.

O que fica com o SOC e o que fica com a instituição?

A terceirização do SOC não transfere integralmente a responsabilidade pela segurança ou pelas obrigações regulatórias. A divisão precisa estar definida em contratos, procedimentos, matrizes de responsabilidade e critérios de escalonamento.

Exemplo anonimizado: redução do tempo de investigação

Em uma instituição financeira brasileira, a investigação da causa raiz de determinadas ocorrências podia levar até três dias. O problema não estava apenas na quantidade de alertas, mas na fragmentação dos dados e na dificuldade para relacionar os sinais técnicos ao contexto da operação.

Com a evolução da visibilidade, da correlação entre fontes e dos gatilhos de investigação, esse tempo passou, geralmente, para uma faixa entre 10 e 30 minutos. As salas de guerra, antes acionadas com frequência para reunir diferentes equipes e reconstruir os acontecimentos, foram praticamente eliminadas.

O resultado não veio apenas da aquisição de ferramentas. A evolução envolveu integração de dados, revisão das regras, enriquecimento de contexto e definição de processos mais claros para investigação e resposta.

O exemplo foi anonimizado para preservar a instituição. Os resultados representam um contexto específico e podem variar conforme arquitetura, escopo, processos, tecnologias e maturidade operacional.

Quais registros ajudam em avaliações regulatórias?

As normas aplicáveis às instituições financeiras e às instituições de pagamento estabelecem responsabilidades relacionadas à política de segurança cibernética, ao tratamento de incidentes, aos controles adotados e ao acompanhamento da efetividade das ações.

Entre as normas que precisam ser consideradas conforme o enquadramento da instituição estão:

• Resolução CMN nº 4.893/2021, que trata da política de segurança cibernética e da contratação de serviços de processamento, armazenamento e computação em nuvem.
• Resolução BCB nº 85/2021, aplicável ao contexto de segurança cibernética das instituições de pagamento.
• Resolução CMN nº 5.274/2025, que atualiza requisitos relacionados à segurança cibernética no âmbito das instituições abrangidas.
• Resolução BCB nº 538/2025, que introduz atualizações correspondentes para instituições sujeitas à regulamentação do Banco Central.

Essas normas precisam ser interpretadas conforme o tipo de instituição, os serviços prestados e o contexto regulatório aplicável. Os registros do SOC são insumos para demonstrar a operação dos controles, mas não substituem a análise de compliance, jurídico, auditoria ou do responsável interno pela governança de riscos.

Como o Advisor identifica lacunas nessa capacidade?

O acompanhamento de maturidade busca entender se pessoas, processos e tecnologias funcionam como uma capacidade integrada. Uma organização pode ter ferramentas relevantes e, ainda assim, enfrentar dificuldades para explicar sua cobertura, reconstruir investigações ou priorizar as lacunas mais importantes.

Por meio do Advisor, a análise pode identificar pontos como:

• Ativos críticos sem visibilidade adequada.
• Fontes conectadas, mas sem qualidade suficiente.
• Casos de uso desalinhados aos riscos do negócio.
• Falta de critérios claros para investigação e escalonamento.
• Ausência de rastreabilidade entre alertas e ações.
• Métricas que medem volume, mas não efetividade.
• Lacunas sem prioridade, responsável ou prazo.
• Dependências entre tecnologia, operação e governança.

O objetivo é diagnosticar o estágio atual e prescrever ações de evolução. Esse acompanhamento não constitui auditoria, certificação ou parecer de conformidade.

Checklist de registros do SOC

Como referência inicial, a instituição pode verificar se a operação mantém e consegue relacionar os seguintes elementos:

• Inventário atualizado de fontes monitoradas.
• Registro de disponibilidade e falhas na coleta.
• Catálogo de casos de uso e riscos associados.
• Histórico de criação, revisão e desativação de regras.
• Alertas com contexto técnico suficiente.
• Tickets com hipóteses, decisões e conclusões.
• Linhas do tempo para incidentes relevantes.
• Registro das ações executadas e recomendadas.
• Critérios de severidade e escalonamento.
• Métricas relacionadas à cobertura e à resposta.
• Lacunas conhecidas e respectivos planos de evolução.
• Histórico de melhorias decorrentes de incidentes.

O checklist não deve ser tratado como uma confirmação automática de conformidade. A suficiência dos registros depende do risco, do ambiente, dos serviços prestados e das obrigações aplicáveis à instituição.

Perguntas frequentes

Um relatório mensal comprova monitoramento contínuo?

Não de forma isolada. O relatório consolida informações, mas precisa ser sustentado por inventários, alertas, tickets, linhas do tempo, métricas e registros de melhoria. Sem esses elementos, pode ser difícil explicar como os indicadores foram produzidos e como as ocorrências foram tratadas.

Ter um SIEM comprova que a instituição monitora o ambiente?

Não. O SIEM é uma tecnologia que centraliza e correlaciona dados, mas a efetividade depende das fontes integradas, da qualidade dos eventos, dos casos de uso, da investigação e dos processos de resposta.

Quais registros são mais importantes?

Não existe um único registro suficiente. A combinação mais relevante costuma envolver inventário de fontes, casos de uso, alertas, tickets, linhas do tempo, ações realizadas, métricas e acompanhamento das lacunas.

O SOC pode apresentar registros em uma auditoria?

O SOC pode disponibilizar registros relacionados ao serviço contratado. A organização e a avaliação da suficiência desses materiais permanecem sob responsabilidade da instituição e dos profissionais responsáveis pela auditoria ou avaliação.

Contratar um SOC garante conformidade com o Banco Central?

Não. O SOC apoia capacidades de monitoramento, detecção, investigação, resposta e registro. A responsabilidade regulatória continua com a instituição, incluindo governança, políticas, gestão de riscos, terceiros e comunicação ao regulador.

Por quanto tempo os logs devem ser mantidos?

O período depende das obrigações regulatórias, finalidades, riscos, contratos e políticas da instituição. A retenção deve considerar também proteção de dados, controle de acesso, integridade, capacidade de investigação e descarte seguro.

O SOC é responsável por notificar o regulador?

Normalmente, o SOC fornece informações técnicas e apoia a caracterização do incidente. A decisão e a comunicação ao regulador permanecem com a instituição, conforme sua governança e suas obrigações aplicáveis.

O próximo passo é avaliar a maturidade da operação

Manter registros não é suficiente quando eles não explicam a cobertura, as decisões e as limitações da operação. A instituição precisa conseguir relacionar riscos, fontes, detecções, investigações, respostas e ações de evolução.

O Runk Advisor ajuda a identificar o estágio atual de maturidade, localizar lacunas e prescrever ações prioritárias para pessoas, processos e tecnologia. O trabalho não substitui auditoria ou certificação: seu objetivo é orientar a evolução da capacidade operacional de segurança.

Conheça a DataRunk e entenda como evoluir sua capacidade de monitoramento, detecção e resposta.

Normas e referências

• Resolução CMN nº 4.893/2021
  
• Resolução BCB nº 85/2021
  
• Resolução CMN nº 5.274/2025
  
• Resolução BCB nº 538/2025
  
• NIST SP 800-92 — Guide to Computer Security Log Management
  
• NIST Cybersecurity Framework
  

Conteúdo informativo. A aplicação dos requisitos deve considerar o enquadramento regulatório, os serviços prestados, os riscos e as responsabilidades específicas de cada instituição. A DataRunk não presta serviços de auditoria ou certificação.