Como um SOC terceirizado apoia os requisitos de segurança do Banco Central?

O Banco Central exige um SOC?

As normas não determinam, de forma geral, que toda instituição contrate um produto denominado “SOC” nem que terceirize essa função. Elas estabelecem resultados, controles e responsabilidades que a instituição precisa sustentar de acordo com seu porte, perfil de risco, modelo de negócio, complexidade e sensibilidade das informações.

A Resolução CMN nº 4.893/2021 trata da política de segurança cibernética e da contratação de serviços de processamento, armazenamento e computação em nuvem por instituições incluídas em seu escopo. A norma recebeu alterações da Resolução CMN nº 5.274/2025.

Para instituições de pagamento e outras categorias submetidas à regulamentação específica do Banco Central, a Resolução BCB nº 85/2021 estabelece uma estrutura relacionada à política de segurança cibernética e à contratação de serviços de processamento e armazenamento de dados. A Resolução BCB nº 538/2025 deve ser considerada na leitura atualizada do tema.

Por isso, a pergunta mais precisa não é “o Banco Central exige um SOC?”, mas:

Quais capacidades de segurança a instituição precisa manter e quais delas podem ser operadas ou apoiadas por um SOC?

Quais capacidades precisam existir?

As regras aplicáveis devem ser interpretadas conforme o enquadramento de cada instituição. Em linhas gerais, elas relacionam segurança cibernética a política formal, controles preventivos e detectivos, resposta a incidentes, rastreabilidade, continuidade, gestão de terceiros, governança e acompanhamento da efetividade.

As alterações regulatórias publicadas em 2025 detalharam controles relacionados a autenticação, criptografia, prevenção e detecção de intrusão, proteção contra vazamentos e códigos maliciosos, rastreabilidade, cópias de segurança, correção de vulnerabilidades, controle de acesso, configuração segura, proteção de rede, certificados digitais, segurança de interfaces e inteligência no ambiente cibernético.

Um SOC participa principalmente das capacidades detectivas e responsivas. Outros controles dependem de áreas distintas e não devem ser atribuídos integralmente à operação de monitoramento.

Qual é o papel do SOC?

Em resumo: o SOC executa e acompanha capacidades específicas, mas a instituição continua responsável por governá-las.

O que significa monitorar na prática?

Monitorar não significa apenas receber logs em uma plataforma. Uma capacidade operacional consistente depende da conexão entre contexto do negócio, fontes de dados, casos de uso, procedimentos e responsáveis.

Fontes relevantes

A seleção precisa partir dos riscos e dos processos críticos. Dependendo da instituição, pode incluir:

• Identidade e autenticação.
• Endpoints e servidores.
• Rede, firewall, DNS e acesso remoto.
• Aplicações críticas e APIs.
• Nuvem e serviços terceirizados.
• Bancos de dados.
• Meios de pagamento e fluxos transacionais.
• Ferramentas de segurança e gestão de vulnerabilidades.

Centralizar grandes volumes sem definir o que precisa ser detectado tende a transferir o problema para o SOC. A operação recebe mais eventos, mas não necessariamente produz mais visibilidade.

Exemplo real: quando a visibilidade reduz o tempo de investigação

Em uma instituição financeira brasileira, a operação precisava investigar problemas que atravessavam segurança, performance e capacidade. Antes da evolução do monitoramento, a identificação da causa raiz podia consumir até três dias e frequentemente exigia a abertura de salas de guerra.

O trabalho concentrou-se em aumentar a visibilidade sobre o ambiente e transformar dados dispersos em sinais acionáveis. Com fontes relevantes correlacionadas, gatilhos definidos e contexto operacional disponível para a investigação, a instituição passou a identificar a causa dos problemas geralmente entre 10 e 30 minutos. Segundo o responsável pela área, as salas de guerra “praticamente zeraram”.

O ponto principal não foi apenas instalar uma ferramenta ou acumular logs. A evolução ocorreu quando a operação passou a:

• Conhecer o comportamento esperado do ambiente.
• Relacionar segurança, performance e capacidade.
• Definir gatilhos para situações que afetavam a equipe ou o negócio.
• Investigar sinais com dados suficientes para chegar à causa raiz.
• Usar a visibilidade operacional para orientar decisões mais rápidas.

O caso ilustra a diferença entre possuir tecnologia de monitoramento e sustentar uma capacidade operacional de detecção e investigação. O nome da instituição e os detalhes da arquitetura foram omitidos para preservar a confidencialidade.

Casos de uso

Cada caso de uso deve relacionar:

• Cenário de risco.
• Ativo ou processo afetado.
• Fontes necessárias.
• Condições de detecção.
• Criticidade.
• Procedimento de investigação.
• Ação autorizada.
• Responsável pelo escalonamento.
• Registro esperado ao final do tratamento.

Esse desenho evita que a detecção seja tratada como um catálogo genérico. Em uma instituição financeira, por exemplo, um comportamento anômalo pode ganhar prioridade diferente quando envolve um ativo que suporta transações, credenciais privilegiadas ou um processo essencial para a continuidade.

Resposta e alçadas

O SOC precisa saber até onde pode agir. Algumas contenções podem ser automatizadas ou previamente autorizadas; outras dependem de decisão da instituição porque afetam disponibilidade, clientes, transações ou obrigações regulatórias.

Um playbook consistente define:

• Critérios de ativação.
• Dados necessários para investigar.
• Ações permitidas ao SOC.
• Pontos de decisão da instituição.
• Responsáveis por tecnologia, negócio, jurídico e comunicação.
• Condições para declarar crise.
• Critérios de encerramento e revisão posterior.

Também é importante diferenciar tempo de resposta de tempo de resolução. A operação pode controlar a triagem, a investigação e o escalonamento, mas a resolução final pode depender de ações e decisões da instituição.

Quais registros o SOC produz?

Uma operação de SOC pode produzir registros que apoiam o acompanhamento dos controles e futuras solicitações de auditoria. Isso não significa que o SOC valide a conformidade ou certifique a suficiência desses registros.

• Inventário das fontes integradas ao monitoramento.
• Catálogo e histórico de alterações dos casos de uso.
• Alertas, investigações e tickets.
• Linha do tempo dos incidentes.
• Evidências consideradas durante a análise.
• Ações executadas e respectivas autorizações.
• Escalonamentos e responsáveis acionados.
• Métricas de detecção e resposta.
• Histórico de falsos positivos e ajustes.
• Recomendações de melhoria.
• Relatórios de cobertura e lacunas conhecidas.

A existência de um registro não demonstra, isoladamente, que o controle é suficiente. É necessário verificar se a fonte é completa, se o caso de uso representa o risco, se a investigação ocorreu dentro do procedimento e se as ações corretivas foram acompanhadas.

A terceirização transfere a responsabilidade?

Não. A instituição precisa supervisionar o serviço, definir expectativas, acompanhar indicadores e manter capacidade de decisão. O contrato deve deixar claros o escopo, as fontes monitoradas, os níveis de serviço, as alçadas, a retenção dos registros, a comunicação de incidentes, a gestão de mudanças e as responsabilidades entre as partes.

Quatro perguntas ajudam a identificar lacunas:

1. O SOC conhece os processos e ativos que não podem parar?
2. Os casos de uso estão ligados aos riscos reais ou apenas às ferramentas disponíveis?
3. As ações de resposta têm responsáveis e alçadas definidos?
4. A instituição consegue reconstruir o tratamento de um incidente do alerta ao encerramento?

Se uma dessas respostas não estiver clara, o problema pode estar menos na tecnologia e mais na maturidade entre pessoas, processos, serviços e contexto de negócio.

Qual é o papel do Runk Advisor?

Quando a instituição ainda não tem clareza sobre o estágio atual, o Runk Advisor pode ser usado como diagnóstico preliminar. A metodologia avalia negócio, pessoas, processos, tecnologia e serviços por meio de uma entrevista guiada, sem acesso direto ao ambiente, e transforma as lacunas identificadas em prioridades de evolução.

O resultado não é uma auditoria, certificação ou declaração de conformidade. O papel do Advisor é:

• Identificar o estágio atual da operação.
• Evidenciar capacidades inexistentes ou pouco estruturadas.
• Relacionar lacunas técnicas ao risco do negócio.
• Prescrever ações e prioridades.
• Apoiar a construção de um roadmap.
• Acompanhar a evolução das ações recomendadas.

Quando a necessidade é operacional, o SOC gerenciado da DataRunk pode assumir ou compartilhar capacidades de monitoramento, investigação, resposta e evolução das detecções conforme o escopo e a matriz de responsabilidades.

Quando o SOC apoia de verdade?

O SOC contribui de forma efetiva quando deixa de ser apenas um receptor de alertas e passa a operar sobre contexto, procedimentos e prioridades definidas. Isso exige integração entre a instituição e o prestador.

O caso anonimizado apresentado neste conteúdo mostra um resultado operacional concreto: a causa raiz, que podia levar até três dias para ser identificada, passou a ser encontrada geralmente entre 10 e 30 minutos após a evolução da visibilidade e dos gatilhos de monitoramento. O ganho não comprova conformidade regulatória, mas demonstra que a capacidade saiu do plano documental e passou a apoiar a resposta cotidiana.

Sinais de uma capacidade mais madura incluem:

• Fontes priorizadas conforme processos e riscos críticos.
• Casos de uso com objetivo, lógica e responsável definidos.
• Playbooks alinhados às alçadas reais.
• Métricas que mostram cobertura e resultado, não apenas volume.
• Revisões após incidentes e ajustes documentados.
• Tratamento explícito das lacunas conhecidas.
• Evolução periódica das detecções.

A regulamentação não deve ser reduzida a uma lista de ferramentas. O objetivo é sustentar capacidades que funcionem no cotidiano e possam ser acompanhadas ao longo do tempo.

Perguntas frequentes

O Banco Central obriga instituições reguladas a contratar um SOC 24×7?

As normas de segurança cibernética estabelecem políticas, controles e responsabilidades, mas não criam uma obrigação geral de contratar um fornecedor chamado SOC 24×7. O modelo operacional deve ser compatível com o porte, os riscos, a complexidade e a criticidade da instituição. Em determinados contextos, a operação contínua pode ser necessária para sustentar a capacidade esperada, mas essa conclusão depende da análise de risco e do enquadramento aplicável.

Contratar um SOC garante conformidade com o Banco Central?

Não. Um SOC apoia capacidades como monitoramento, detecção, investigação, resposta e registro. A instituição continua responsável pela política, governança, gestão de riscos, continuidade, terceiros, decisões e comunicações regulatórias.

Um SIEM é suficiente para atender aos requisitos de monitoramento?

Não isoladamente. O SIEM centraliza e correlaciona dados, mas a capacidade depende de fontes adequadas, casos de uso, procedimentos, analistas, automações, alçadas e melhoria contínua. Ferramenta sem processo pode apenas concentrar eventos sem transformar dados em resposta.

O SOC pode comunicar um incidente ao Banco Central?

O SOC pode identificar, registrar, investigar e escalar o incidente conforme o procedimento contratado. A decisão e a responsabilidade pela comunicação regulatória permanecem com a instituição, salvo arranjo formal específico que respeite as responsabilidades aplicáveis.

Quais registros do SOC podem apoiar o acompanhamento regulatório?

Alertas, tickets, linhas do tempo, evidências analisadas, ações executadas, escalonamentos, métricas, alterações em regras e histórico de melhorias podem apoiar o acompanhamento. A suficiência desses registros precisa ser avaliada conforme a norma, o risco e o escopo analisado.

O Banco Central exige monitoramento de deep e dark web?

As alterações regulatórias de 2025 passaram a detalhar ações de inteligência no ambiente cibernético entre os controles mínimos, abrangendo informações de interesse da instituição na internet, na deep web, na dark web e em grupos privados de comunicação. O escopo operacional deve ser definido com base no enquadramento, nos riscos e nas informações relevantes para a instituição.

Como começar se a instituição não conhece sua maturidade atual?

O primeiro passo é estabelecer um ponto de partida para as capacidades existentes, as lacunas e as dependências do negócio. O Runk Advisor realiza um diagnóstico preliminar por entrevista e prescreve prioridades e uma jornada de evolução; ele não substitui uma avaliação técnica profunda, auditoria ou certificação.

Próximo passo

Antes de ampliar ferramentas ou transferir mais alertas para um SOC, identifique quais capacidades já existem, onde estão as lacunas e quais ações devem ser priorizadas.

O Runk Advisor ajuda a estabelecer esse ponto de partida e a prescrever uma jornada de evolução alinhada ao risco e ao momento da operação — sem prometer conformidade automática, auditoria ou certificação.

Avalie a maturidade atual da sua operação de segurança.