Todo ano, até 31 de março, o conselho de administração de uma instituição autorizada pelo Banco Central recebe um relatório sobre a implementação do plano de ação e de resposta a incidentes. É o art. 8º da Resolução CMN nº 4.893, e o art. 8º da Resolução BCB nº 85 para instituição de pagamento. Em dezembro de 2025 esse artigo ganhou um inciso novo, e ele mudou quem precisa estar envolvido muito antes de março: o relatório passou a ter de trazer os resultados dos testes de intrusão e os planos de ação para corrigir o que eles acharem. Este texto percorre o que o art. 8º pede, mostra por que a data que realmente decide é 31 de dezembro e não 31 de março, e o que uma operação apoiada na Wardizon precisa ter produzido antes disso para que o parágrafo exista.
Que relatório é esse
O art. 8º manda a instituição elaborar relatório anual sobre a implementação do plano de ação e de resposta a incidentes de que trata o art. 6º, com data-base de 31 de dezembro. Não é um relatório de segurança em geral: é a prestação de contas de um plano específico, que segundo o art. 6º abrange as ações para adequar as estruturas organizacional e operacional à política de segurança cibernética, as rotinas, procedimentos, controles e tecnologias usados na prevenção e resposta a incidentes, e a área responsável pelo registro e controle dos efeitos de incidentes relevantes.[1]
Ele tem destinatário com nome. O § 2º manda submetê-lo ao comitê de risco, quando existente, e apresentá-lo ao conselho de administração ou, na sua inexistência, à diretoria, até 31 de março do ano seguinte ao da data-base. E o art. 7º exige que a instituição designe um diretor responsável pela política de segurança cibernética e pela execução do plano. Há uma pessoa física que assina, e para ela o relatório não é burocracia: é o documento pelo qual ela responde.[1]
Para quem vende serviço de segurança, isso muda a conversa de lugar. O interlocutor não é o analista que recebe o relatório técnico; é quem vai ter de apresentar um resumo ao conselho em março e não quer chegar lá com uma linha em branco.
Os cinco itens mínimos do § 1º
O § 1º lista o que o relatório deve abordar, no mínimo. Eram quatro itens até dezembro de 2025; passaram a cinco:[1]
O inciso V foi incluído pela Resolução CMN nº 5.274 e, do lado das instituições de pagamento, pela Resolução BCB nº 538 — as duas publicadas em 18 de dezembro de 2025, com o mesmo texto. Antes dele, nada no art. 8º obrigava a falar de teste de intrusão no relatório. Agora o teste e o plano de correção são conteúdo mínimo.[3][4]
- A efetividade da implementação das ações descritas no art. 6º, parágrafo único, inciso I.
- O resumo dos resultados obtidos na implementação das rotinas, procedimentos, controles e tecnologias de prevenção e resposta a incidentes.
- Os incidentes relevantes relacionados com o ambiente cibernético ocorridos no período.
- Os resultados dos testes de continuidade, considerando cenários de indisponibilidade ocasionada por incidentes.
- Os resultados dos testes de intrusão e dos testes, varreduras e análises periódicas para detecção de vulnerabilidades do art. 3º, § 8º, e os planos de ação estabelecidos para as suas correções.
O que o inciso V realmente pede
O inciso V não pede “um pentest”. Ele remete ao art. 3º, § 8º, que elenca o que a avaliação e a correção de vulnerabilidades devem contemplar, no mínimo — cinco coisas, das quais o teste de intrusão é uma:[1][3]
E remete também ao art. 22-A, caput, inciso III, que exige que os resultados da execução sejam documentados, especialmente as eventuais vulnerabilidades identificadas e os planos de ação estabelecidos para suas correções. Juntando as duas remissões: o relatório precisa dizer o que foi testado, o que apareceu e o que foi combinado para corrigir — com plano, não com intenção.[3]
Vale reparar no que não está lá. O inciso V não pede que as vulnerabilidades estejam corrigidas; pede os resultados e os planos. Mas um relatório que repete os mesmos achados ano após ano, sempre com plano e nunca com fecho, conta uma história ao conselho — e é uma história que o diretor designado pelo art. 7º vai ter de explicar.
- Testes e análises periódicos para detecção de vulnerabilidades em sistemas de informação.
- Varreduras periódicas para identificar dispositivos indevidamente conectados à rede corporativa.
- Análises periódicas dos recursos tecnológicos em busca de vulnerabilidades que comprometam os ativos.
- Testes de intrusão.
- Correção tempestiva das vulnerabilidades identificadas.
A data que decide é 31 de dezembro
O art. 8º tem duas datas e elas fazem coisas diferentes. A data-base é 31 de dezembro: é ela que delimita o período sobre o qual o relatório fala. A apresentação é até 31 de março do ano seguinte: é o prazo para levar o documento pronto ao conselho. Quase toda a conversa de mercado gira em torno de março, e é a data errada para se preocupar.[1]
O inciso V pede os resultados dos testes do período. Um teste executado em fevereiro não entra no relatório da data-base anterior — entra no próximo. Quem chega a 31 de dezembro sem ter testado não tem como preencher o inciso V depois, porque o conteúdo que falta não é um documento a redigir: é uma execução que não aconteceu dentro do período. O prazo real, portanto, é o fim do ano-base, e o de março é só a entrega.
O primeiro relatório que inequivocamente carrega o inciso V é o de data-base 31 de dezembro de 2026, a ser apresentado até 31 de março de 2027. As duas resoluções de dezembro de 2025 entraram em vigor na data da publicação, mas deram às instituições em funcionamento até 1º de março de 2026 para se adequar — o que deixa em aberto, para o relatório de data-base 31 de dezembro de 2025, uma questão que é da assessoria jurídica de cada instituição, não deste texto. Para o ano-base de 2026 não há essa dúvida.[3][4]
Onde os dois regimes não são iguais
O art. 8º da BCB 85 é quase o mesmo da 4.893, e as duas receberam o inciso V com texto idêntico. Mas há duas diferenças que decidem a quem o documento é levado e o que ele mede, e vale saber qual delas é a do seu cliente.[1][2]
A primeira está no § 2º. Na 4.893 ele tem dois passos: submeter ao comitê de risco, quando existente, e apresentar ao conselho de administração ou à diretoria até 31 de março. Na BCB 85 há só o segundo passo — a apresentação ao conselho ou à diretoria, sem a etapa do comitê de risco.[1][2]
A segunda está no inciso IV. Na 4.893 são os resultados dos testes de continuidade de negócios; na BCB 85, os resultados dos testes de continuidade dos serviços de pagamento prestados. É a mesma ideia recortada sobre a atividade de cada tipo de instituição, e muda o que o seu cliente precisa ter exercitado.[1][2]
O que o MSP realmente deve entregar
O entregável que o art. 8º cobra não é um teste: é um parágrafo. Alguém vai escrever, no relatório que o conselho recebe, o que foi testado no período, o que foi encontrado e o que está planejado para corrigir. Se o MSP entrega um PDF técnico de oitenta páginas e nada mais, esse parágrafo é escrito por outra pessoa, que não acompanhou a execução — e é aí que o resumo fica vago o bastante para não servir a ninguém.
Há uma diferença prática entre fornecer o insumo e fornecer o item do relatório. O insumo é a lista de achados. O item é a lista com data de execução, escopo autorizado, severidade, evidência e o plano de correção com responsável e prazo — que é exatamente o que o art. 22-A, inciso III, manda documentar. Entregar o segundo é mais trabalho e é o que faz o cliente voltar no ano seguinte.[3]
E há o reteste, que não aparece em nenhum inciso e resolve o problema do terceiro parágrafo da seção anterior. Um achado reaberto e verificado depois da correção transforma “planejamos corrigir” em “corrigimos, e aqui está a verificação”. Para o diretor que assina, é a diferença entre apresentar um plano e apresentar um resultado.
O que uma operação apoiada na Wardizon produz até dezembro
O período que o relatório cobre começa e termina em datas fixas, então tudo depende de a execução estar dentro dele e de haver registro disso. Numa operação apoiada na Wardizon, o que fixa esse marco é a autorização: as Regras de Engajamento assinadas pelo cliente, com os alvos, a janela, a profundidade e quem aprovou. É o registro que responde “quando foi testado e sob qual autorização”, que é a primeira pergunta de quem redige o item.[5]
O relatório entregue ao cliente traz a marca do MSP com a assinatura “Powered by Wardizon”, e carrega os achados com evidência, a severidade e a orientação de correção. É desse material que sai o plano de ação com responsável e prazo, e é ele que o reteste dentro da mesma RoE fecha quando a correção é aplicada. Nada disso declara conformidade sozinho — o juízo sobre risco residual e sobre o que vai ao conselho é da instituição.[6]
O mapeamento para áreas de controle é o que permite ligar cada achado ao inventário que a instituição já mantém, de modo que o item do relatório não seja uma lista solta de vulnerabilidades e sim algo que conversa com o resto do plano do art. 6º. A conta de tempo é simples: se o ano-base fecha em 31 de dezembro, a execução, a correção e o reteste precisam caber antes disso.[7]
O que este texto não é
Este artigo descreve o que as resoluções dizem; não substitui a leitura dos textos oficiais nem a assessoria jurídica da instituição. Em particular, a aplicação do inciso V ao relatório de data-base 31 de dezembro de 2025 depende de uma leitura sobre o prazo de adequação que cabe a cada instituição e ao seu jurídico, não a um fornecedor. As quatro resoluções citadas estão publicadas no Diário Oficial da União e são curtas.[1][2][3][4]
Uma execução dentro do ano-base precisa de data e autorização registradas antes de começar: o modelo de Regras de Engajamento traz as doze cláusulas, o checklist de pré-voo e o e-mail de autorização para enviar à instituição.