- Um plano de resposta a incidentes fornece à equipe um quadro de decisão no momento em que a carga cognitiva é mais alta. Sem um plano, todas as perguntas sobre quem faz o quê e quem pode autorizar o quê são respondidas durante o incidente, sob pressão, com informações incompletas.
- As seis fases são: Preparação, Identificação, Contenção, Erradicação, Recuperação e Avaliação. Cada fase tem atividades delimitadas, responsáveis e resultados esperados.
- A LGPD (Art. 48) obriga o comunicado à ANPD em até 2 dias úteis após o conhecimento do incidente. O Bacen exige notificação de incidentes relevantes de instituições financeiras em prazo específico. Ambos os prazos correm a partir da ciência do incidente.
- Os playbooks são extensões específicas por cenário do PRI: ransomware, fraude em e-mail corporativo (BEC), roubo de credenciais, vazamento de dados e comprometimento da cadeia de suprimentos como mínimo.
- Um plano não testado é uma suposição. Realize pelo menos um tabletop por ano. Teste a recuperação de backup trimestralmente comparando com o tempo máximo tolerável de interrupção.
- O PRI é uma entrega da fase 1 do seu roteiro de cibersegurança e deve existir antes que seu programa de segurança esteja maduro.
Para que serve um plano de resposta a incidentes
Um incidente de segurança coloca a equipe de resposta sob pressão simultânea de várias direções: triagem técnica, exposição jurídica, escalada para a liderança, possível notificação à ANPD, comunicação com clientes, risco de mídia e decisões sobre continuidade de negócios, tudo ao mesmo tempo. O plano de resposta a incidentes não elimina essa pressão. Ele elimina a necessidade de tomar decisões estruturais sob ela.
Quem decide isolar um servidor comprometido? Quem pode autorizar contratar perícia forense externa no fim de semana? Quem aprova o e-mail para clientes? Quem contata a ANPD? Essas perguntas têm um único momento certo para ser respondidas: durante o planejamento, antes de um incidente. Um PRI documentado, testado pela equipe, converte essas decisões em procedimentos. Esse é o retorno sobre o investimento.
O plano não precisa ser longo. Um documento de dez páginas que a equipe de RI leu, praticou e consegue encontrar sem depender de sistemas comprometidos vale mais do que um documento de sessenta páginas guardado numa pasta do SharePoint que ninguém abriu.
As seis fases da resposta a incidentes
O ciclo de vida do NIST para resposta a incidentes define quatro fases. A maioria dos especialistas em RI as expande para seis, tratando Contenção e Erradicação separadamente, o que é mais útil operacionalmente. As seis fases abaixo refletem a prática padrão para organizações brasileiras.
Montando a equipe de resposta a incidentes
A equipe de RI não é um time permanente esperando por incidentes. É uma lista de pessoas nomeadas com papéis definidos que são ativadas quando o processo de resposta é iniciado. Para a maioria das organizações brasileiras fora do segmento enterprise, as mesmas pessoas acumulam múltiplos papéis.
Cada papel tem uma pessoa primária nomeada e um substituto nomeado. Incidentes não se ajustam ao calendário de férias. A lista de contatos deve incluir números de celular pessoais e um caminho de escalada fora do horário comercial que não dependa do e-mail corporativo, que pode estar comprometido.
Seu PRI deve conter informações de contato pré-identificadas para: a linha de resposta a incidentes do seu seguro cibernético (disponível 24/7 na maioria das apólices), uma empresa forense externa caso sua equipe interna não tenha capacidade, seu provedor gerenciado de segurança quando aplicável, o CERT.br para coordenação de resposta a incidentes e o portal de comunicação da ANPD para notificação de incidentes. Procurar esses contatos no meio de um incidente desperdiça tempo que você não tem.
Obrigações legais de notificação
Os prazos legais brasileiros contam a partir do momento em que você tem ciência do incidente, não do momento em que ele começou. Um vazamento de dados que durou três meses antes de ser descoberto ainda inicia o prazo de 2 dias úteis no momento da descoberta. O plano deve conter um procedimento para avaliar se uma obrigação de notificação surgiu e quem é responsável por essa avaliação e pelo envio da notificação.
| Regulador | Gatilho | Prazo | Quem notifica | O que é exigido |
|---|---|---|---|---|
| ANPD (LGPD Art. 48) | Incidente de segurança que possa acarretar risco ou dano relevante aos titulares | 2 dias úteis após ciência | Controlador de dados (DPO ou responsável designado) | Data do incidente, categorias e número estimado de titulares afetados, dados pessoais envolvidos, possíveis consequências, medidas adotadas ou a adotar. A ANPD pode solicitar informações complementares. |
| Bacen (Res. 4.658/2018) | Incidente relevante que afete serviços de processamento de dados ou sistemas de informação de instituição financeira | Imediato para incidentes graves; prazo definido pela política interna de cada instituição | Área de compliance ou responsável designado | Natureza do incidente, impacto real ou potencial, providências adotadas. Atualizações periódicas conforme situação evolui. Relatório final em até 10 dias. |
| CERT.br | Incidentes de segurança em redes conectadas à Internet brasileira; reporte voluntário encorajado | Sem prazo obrigatório; quanto antes, melhor para coordenação | Equipe técnica de RI | Relatório de incidente via formulário em cert.br com indicadores de comprometimento e descrição do ataque. CERT.br pode apoiar na coordenação e resposta. |
| Titulares dos dados (LGPD Art. 48 §1) | Incidente que possa acarretar risco ou dano relevante aos titulares | Prazo razoável, conforme orientação da ANPD | Controlador de dados | Comunicação direta aos titulares afetados com descrição da natureza do incidente, dados envolvidos, medidas tomadas e meios de contato para esclarecimentos. |
O prazo de 2 dias úteis da LGPD é consistentemente mal compreendido. Não é necessário ter um quadro completo do incidente. A ANPD espera a notificação com as informações disponíveis no momento, seguida de atualizações conforme a investigação avança. Aguardar a conclusão completa da investigação arrisca uma constatação regulatória de notificação intempestiva. O DPO ou responsável deve fazer uma avaliação inicial nas primeiras horas após um incidente e enviar uma notificação preliminar se houver qualquer possibilidade de dados pessoais terem sido afetados.
Playbooks de incidente
Um playbook é uma checklist específica por cenário adicionada ao PRI. Cada playbook cobre um tipo de incidente e define: os sinais de detecção que indicam esse tipo de incidente, as primeiras cinco ações nos primeiros 30 minutos, as etapas de contenção em ordem, os requisitos de preservação de evidências, a checklist de obrigações de notificação para esse cenário, modelos de comunicação e o procedimento de recuperação.
Cinco playbooks cobrem os incidentes com maior probabilidade de afetar empresas brasileiras em 2025 e 2026:
| Tipo de incidente | Principais sinais de detecção | Prioridade imediata de contenção | Gatilho de notificação |
|---|---|---|---|
| Ransomware | Arquivos com extensão desconhecida, bilhete de resgate na área de trabalho, alerta de EDR para criptografia em massa de arquivos, pico repentino de atividade de I/O | Isolar os sistemas afetados da rede imediatamente. Não desligar (preserva forense de memória). Identificar o paciente zero antes de iniciar a recuperação a partir de backup. | Notificar ANPD se dados pessoais foram criptografados ou exfiltrados. Seguro cibernético em poucas horas. CERT.br para coordenação. |
| Fraude em e-mail corporativo (BEC) | Solicitação de pagamento fraudulenta recebida, fornecedor reporta não ter recebido pagamento redirecionado, regra de encaminhamento para endereço externo, tentativa de login de localização incomum | Congelar a ordem de pagamento pendente. Contatar imediatamente o banco receptor para solicitação de recuperação. Identificar a caixa de e-mail comprometida e revogar todas as sessões ativas. | Notificar ANPD se dados pessoais foram acessados na caixa de e-mail. Financeiro e liderança imediatamente. Considerar boletim de ocorrência. |
| Roubo de credenciais / tomada de conta | Alerta de password spray, sinal de login com localização impossível, alerta de fadiga de MFA de um colaborador, aplicativo OAuth desconhecido com acesso a dados corporativos | Redefinir senha e revogar todas as sessões ativas da conta comprometida. Verificar mecanismos de persistência: novas regras de processamento de e-mail, permissões de app OAuth, contatos de recuperação adicionados ou novos métodos de MFA. | Notificar ANPD se a conta comprometida tinha acesso a dados pessoais. Determinar o escopo do acesso a dados antes da decisão de notificação. |
| Vazamento de dados / exfiltração | Alerta de grande transferência de dados de saída, alerta de DLP para upload de arquivo sensível, e-mail de extorsão com referência a dados corporativos, terceiro reporta ter recebido dados de seus clientes | Identificar e fechar a rota de exfiltração. Preservar logs antes que sejam sobrescritos. Acionar jurídico para avaliar privilégio antes de conduzir entrevistas. | Notificação à ANPD muito provável se dados pessoais confirmados. Notificar titulares afetados se houver alto risco de dano. CERT.br para coordenação. |
| Comprometimento da cadeia de suprimentos | Notificação de fornecedor de software sobre atualização comprometida, comportamento incomum de aplicativo confiável, MSP reporta acesso não autorizado via suas ferramentas | Isolar os sistemas afetados. Suspender acesso do fornecedor. Não atualizar o software até que o fornecedor confirme uma versão limpa. Iniciar investigação sobre o que o fornecedor conseguia acessar. | Notificar ANPD se dados pessoais estavam acessíveis via acesso do fornecedor. Informar o seguro cibernético. CERT.br se impacto significativo em serviços críticos. |
Preservação de evidências
Evidências digitais coletadas durante um incidente servem a dois propósitos: subsidiar a investigação técnica e apoiar possíveis processos judiciais ou procedimentos regulatórios. Os dois têm padrões diferentes. Evidências admissíveis em processos judiciais ou regulatórios devem ser coletadas e tratadas de forma que demonstre sua integridade. A coleta improvisada compromete os dois propósitos.
O plano especifica: quem tem autoridade para coletar evidências forenses, quais ferramentas estão aprovadas para coleta, como as evidências são armazenadas e a cadeia de custódia é documentada, e em que ponto uma empresa forense externa deve ser acionada. Para a maioria das organizações brasileiras, esse limiar é qualquer incidente com potencial real para processos judiciais, ações regulatórias ou investigação criminal.
Não reimagear ou restaurar sistemas comprometidos antes de fazer coleta forense de memória e imagens de disco. A evidência desaparece quando o sistema é apagado. Acione o contato forense antes de tomar a decisão de recuperação.
Comunicação durante um incidente
Erros de comunicação durante incidentes causam tanto dano quanto erros técnicos. Dois problemas distintos ocorrem. A comunicação interna falha quando a equipe de resposta opera simultaneamente em muitos canais, pessoas sem visão completa escalaram para a liderança ou a mesma atualização chega por pessoas diferentes com formulações diferentes. A comunicação externa falha quando alguém sem autorização fala com a imprensa, clientes ou reguladores.
Comunicação interna
Designe um canal para coordenação da resposta ao incidente e outro para atualizações à liderança. Mantenha-os separados. O canal de coordenação é para detalhes técnicos; o canal de liderança é para impacto e decisões. O escriba é responsável por atualizações cronometradas no canal de coordenação. O líder de comunicação as transforma em briefings à liderança em intervalos definidos, não sob demanda.
Comunicação externa
Modelos de comunicação pré-aprovados no plano economizam tempo e evitam erros. Os modelos devem cobrir: notificação a clientes (vazamento de dados), notificação a fornecedores (se o incidente envolver a cadeia de suprimentos), declaração à imprensa e comunicado à ANPD. Modelos não são scripts, mas pontos de partida. A revisão jurídica antes do envio é obrigatória para qualquer conteúdo que saia da organização.
A pergunta nunca é se você vai se comunicar durante um incidente. É como você se comunica com precisão, dentro do prazo certo, para as pessoas certas, sem agravar a posição jurídica da empresa.
Testando o plano
Um PRI não testado é um documento. Um PRI testado é uma capacidade. A diferença é significativa quando um incidente real ocorre às 2h da manhã de uma sexta-feira.
Simulações de tabletop
Uma simulação de tabletop conduz a equipe de RI por um cenário de incidente realista sem afetar sistemas reais. Um facilitador apresenta um cenário (ransomware criptografou seu servidor de arquivos, é sábado de manhã e o analista de plantão acabou de ligar). A equipe trabalha em tempo real suas decisões: a quem você liga, o que isola, quando notifica a ANPD, quem informa o CEO, você paga o resgate?
Os tabletops revelam decisões que não foram tomadas antecipadamente, contatos ausentes da lista e lacunas de autoridade onde ninguém sabe quem pode aprovar o quê. Custam meio dia e são o investimento de segurança com melhor custo-benefício disponível. Realize pelo menos um por ano. Atualize o PRI em até duas semanas após cada simulação com as descobertas.
Simulações técnicas
Uma simulação técnica testa procedimentos específicos de resposta em sistemas reais em um ambiente controlado. Restaure um sistema a partir de backup e meça o tempo contra seu tempo máximo tolerável de interrupção. Execute uma campanha de phishing simulada e teste o procedimento de detecção e escalada. Confirme que sua ferramenta de EDR gera o alerta esperado quando uma ferramenta maliciosa conhecida é executada em um endpoint. As simulações técnicas confirmam que as ferramentas funcionam como esperado e que a equipe sabe como usá-las sob pressão.
Testes de recuperação de backup
Teste a recuperação de backup trimestralmente. Não verificar se o backup existe, mas efetivamente restaurar um sistema ou conjunto de dados a partir do backup e confirmar que funciona. Valide o tempo de recuperação contra seu tempo máximo tolerável de interrupção. Se a recuperação leva oito horas e seu MTI é de quatro horas, você tem uma lacuna que precisa ser resolvida antes de um incidente, não durante.
Mantendo o plano atualizado
Um PRI que não é atualizado se torna um problema. Ele contém números desatualizados, referências a sistemas que não existem mais e atribuições de papéis a pessoas que saíram da organização. Um plano que a equipe sabe estar desatualizado não será seguido sob pressão.
Revise o plano em três gatilhos: após cada incidente (em até duas semanas), após cada simulação de tabletop (em até duas semanas) e anualmente como parte da revisão geral do programa de segurança. A revisão anual verifica se todos os contatos estão atuais, se os requisitos legais de notificação refletem a legislação vigente, se o inventário de ativos no plano corresponde ao ambiente real e se mudanças organizacionais (novos sistemas, novas unidades de negócio, novos fornecedores) foram incorporadas.
Atribua ao plano um responsável nomeado com uma data de revisão definida. Quando essa data passa sem revisão, o plano está em atraso. Trate com a mesma disciplina de governança do seu roteiro de cibersegurança.
O plano de resposta a incidentes é uma entrega da fase 1 do seu roteiro de cibersegurança. Ele deve existir e ser testado antes que seu programa de segurança mais amplo esteja maduro, porque você precisa de uma capacidade de resposta antes de ter um programa de segurança completo. Se você ainda não tem um PRI documentado, trate-o como o item de maior prioridade no seu backlog de segurança, antes de ferramentas, antes de políticas, antes de treinamentos. Você pode aperfeiçoar todo o resto enquanto o plano existe. Você não pode aperfeiçoar sua resposta a um incidente que acontece antes de o plano existir.
