A convergência entre segurança cibernética e risco operacional
Durante anos, o risco cibernético foi gerido de forma relativamente isolada nas instituições financeiras: a área de segurança da informação cuidava de incidentes técnicos, a área de risco operacional cuidava de perdas de processos, e as duas raramente se falavam de forma estruturada.
A Circular BCB 3.979 rompeu com essa separação ao incluir explicitamente o risco cibernético como subcategoria do Tipo 8 de eventos de risco operacional — ao lado dos riscos sociais, ambientais e climáticos. A lógica é clara: ataques cibernéticos geram perdas financeiras mensuráveis, e essas perdas devem ser registradas, quantificadas e reportadas ao regulador da mesma forma que qualquer outra perda operacional.
Para os bancos S3, essa convergência tem uma implicação prática imediata: a equipe de risco operacional precisa ter acesso estruturado aos dados de incidentes cibernéticos — e a equipe de segurança da informação precisa compreender que seus registros alimentam o CADOC 5050.
Além da Circular BCB 3.979, os bancos S3 estão sujeitos à Resolução BCB 85/2021 (gestão de riscos de segurança cibernética) e à Resolução BCB 4/2020 (política de segurança cibernética). A gestão do risco cibernético, portanto, tem obrigações regulatórias em duas frentes — e o CADOC 5050 é o ponto de convergência entre elas.
Quais eventos cibernéticos geram perdas operacionais
Nem todo incidente de segurança da informação gera uma perda operacional no sentido regulatório. Para fins do CADOC 5050, o que importa é a perda financeira efetiva ou contingente decorrente do incidente. A tabela abaixo detalha os principais tipos de evento e sua relação com o registro na base de perdas:
Ataque que criptografa sistemas e exige resgate. Gera perdas por interrupção de negócios, custos de recuperação, eventual pagamento de resgate e multas regulatórias.
Exposição não autorizada de dados de clientes ou da instituição. Gera multas da ANPD (LGPD), custos de notificação e remediação, além de perdas reputacionais mensuráveis.
Sobrecarga de sistemas que causa indisponibilidade de serviços. Se houver perda financeira mensurável (ex: transações não processadas, multas contratuais), deve ser registrado.
Acesso não autorizado a sistemas por roubo ou engenharia social de credenciais. Gera perdas diretas se resultar em transações fraudulentas ou exfiltração de dados.
Fraudes externas via phishing que resultam em perdas para clientes reembolsadas pela instituição. Classificar como Tipo 2 (Fraude Externa) se a perda for coberta pelo banco.
Interrupção de sistema causada por ataque cibernético. Diferente de falha técnica comum: se a origem for um ataque, classificar como Tipo 8, não Tipo 6.
O erro de classificação mais comum: Tipo 6 vs. Tipo 8
O equívoco mais recorrente que observamos em bancos S3 é a classificação de incidentes cibernéticos como Tipo 6 — Interrupção de Negócios e Falhas em Sistemas, quando deveriam ser registrados como Tipo 8 — Risco Cibernético.
A distinção é relativamente simples na teoria, mas frequentemente ignorada na prática: o critério determinante é a origem do evento, não sua consequência. Uma indisponibilidade de sistema causada por falha de hardware ou bug de software é Tipo 6. A mesma indisponibilidade causada por um ataque ransomware ou DDoS é Tipo 8.
A dupla obrigação regulatória dos bancos S3
Um aspecto que frequentemente passa despercebido é que os bancos S3 têm duas obrigações regulatórias distintas relacionadas ao risco cibernético, e que precisam ser geridas de forma coordenada — mas não são a mesma coisa:
- Registrar perdas financeiras de incidentes cibernéticos na base de perdas operacionais
- Classificar corretamente como Tipo 8 na taxonomia da Circular 3.979
- Reportar ao BACEN via CADOC 5050 (data-base jun/2027)
- Manter histórico mínimo de 5 anos
- Responsável: área de Risco Operacional
- Manter política de segurança cibernética (Res. BCB 4/2020)
- Implementar controles de segurança e plano de resposta a incidentes
- Reportar incidentes relevantes ao BACEN no prazo regulatório
- Manter registro de incidentes de segurança (não necessariamente financeiros)
- Responsável: área de Segurança da Informação / TI
O problema prático é que, na maioria dos bancos S3, essas duas obrigações são geridas em silos completamente separados. A área de segurança registra incidentes técnicos em suas próprias ferramentas (SIEM, ticketing, etc.), enquanto a área de risco operacional mantém sua base de perdas sem acesso sistemático a esses registros.
Isso cria um gap estrutural: incidentes cibernéticos com perdas financeiras mensuráveis simplesmente não chegam à base de perdas do CADOC 5050 — nem por falta de dados, mas por falta de integração entre as áreas.
Em diagnósticos realizados pela ARR Consultoria, é comum encontrar bancos S3 com registros detalhados de incidentes de segurança no SIEM, mas com zero eventos cibernéticos na base de perdas operacionais — simplesmente porque ninguém criou o processo de transferência entre as duas áreas.
Como estruturar a captura de perdas cibernéticas
A solução para esse gap não é tecnológica — é processual. O que precisa existir é um fluxo formal de comunicação entre a área de segurança da informação e a área de risco operacional sempre que um incidente cibernético resultar em perda financeira ou contingência relevante.
- Definir critérios de acionamento: estabelecer quais tipos de incidentes cibernéticos obrigatoriamente geram uma notificação à área de risco operacional (ex.: qualquer incidente com impacto financeiro acima do limiar de captura).
- Criar formulário de reporte cruzado: um documento padronizado que a equipe de segurança preenche quando um incidente atinge o critério de acionamento, contendo: data de ocorrência, natureza do ataque, sistemas afetados, impacto financeiro estimado e status de recuperação.
- Estabelecer responsabilidade clara: definir quem, na área de risco, é responsável por receber, validar e registrar o evento na base de perdas — incluindo a classificação correta como Tipo 8.
- Retroalimentar o histórico: para a base de perdas do CADOC 5050, é necessário retroalimentar pelo menos 5 anos de eventos. Isso significa revisitar os logs de incidentes de segurança dos últimos anos e identificar aqueles com perdas financeiras que nunca foram registrados na base de GRO.
- Documentar o processo: o BACEN poderá questionar como a instituição garante que eventos cibernéticos com perdas são capturados. A existência de um processo documentado e auditável é fundamental.
- Não registrar incidentes sem perda: a base de perdas do CADOC 5050 registra apenas eventos com impacto financeiro efetivo ou contingente acima do limiar. Incidentes técnicos sem perda associada não pertencem a esta base — pertencem ao registro de incidentes de segurança.
Quantificação das perdas cibernéticas: o que incluir
Uma das dúvidas mais comuns é sobre o que exatamente deve ser quantificado como "perda" em um evento cibernético. A Circular BCB 3.979 adota uma visão ampla de perda operacional, que inclui:
| Componente da perda | Incluir na base? | Observação |
|---|---|---|
| Pagamento de resgate (ransomware) | Sim | Perda direta — valor integral |
| Custos de resposta e remediação (consultoria, forense) | Sim | Despesas extraordinárias associadas ao evento |
| Multas da ANPD / BACEN por violação | Sim | Perda regulatória — registrar quando aplicada |
| Receita perdida por indisponibilidade de sistemas | Sim | Se mensurável — exige metodologia de cálculo documentada |
| Indenizações a clientes por vazamento de dados | Sim | Perda indenizatória — registrar quando liquidada |
| Custos de melhoria de infraestrutura pós-incidente | Não | Investimento de capital, não perda operacional |
| Recuperações de seguro cibernético | Descontar | Registrar a perda bruta e a recuperação separadamente |
Conclusão: o risco cibernético como prioridade imediata
A inclusão do risco cibernético como categoria obrigatória no CADOC 5050 não foi uma escolha aleatória do Banco Central. Ela reflete uma realidade inegável: o setor financeiro é o principal alvo de ataques cibernéticos no Brasil, e as perdas decorrentes desses ataques são cada vez mais significativas no perfil de risco operacional das instituições.
Para os bancos S3, o desafio imediato é duplo. Por um lado, é preciso criar os processos que garantam a captura sistemática de eventos cibernéticos na base de perdas a partir de agora. Por outro, é necessário retroalimentar o histórico dos últimos 5 anos — o que exige uma revisão cuidadosa dos registros de incidentes de segurança passados com olhos de risco operacional.
Essa não é uma tarefa simples, mas é absolutamente viável — desde que iniciada com tempo suficiente antes do prazo de junho de 2027.
Apoiamos bancos S3 na integração entre as áreas de segurança cibernética e risco operacional, na revisão do histórico de incidentes e na estruturação do processo de captura de perdas cibernéticas para o CADOC 5050. Agende uma conversa com nossos especialistas.