- Um plano de resposta a incidentes é principalmente um documento de pessoas e processos. Ele define quem decide, em que ordem e com que autoridade. Sem essa estrutura, as etapas técnicas falham.
- A revisão 3 do NIST SP 800-61 (abril de 2025) passou a enquadrar a resposta a incidentes no NIST Cybersecurity Framework 2.0. Para os procedimentos do dia a dia, a maioria das equipes ainda trabalha em seis etapas operacionais, desde a Preparação até a Atividade Pós-Incidente. Quem pula a revisão pós-incidente repete os mesmos erros.
- Guarde o plano num lugar acessível mesmo com os sistemas fora do ar ou criptografados, e imprima uma cópia. Um plano que só existe na rede some justamente nos incidentes para os quais foi escrito.
- Os prazos de notificação dependem de onde você opera e de quais dados são afetados: três dias úteis para a ANPD pela LGPD, 72 horas para o regulador europeu pelo GDPR e quatro dias úteis para um incidente material em uma empresa listada nos EUA. Um único incidente pode disparar vários prazos ao mesmo tempo, por isso o plano deve listar todos os regimes que se aplicam a você.
- Os exercícios de tabletop costumam revelar as mesmas lacunas: caminhos de escalonamento pouco claros, uma lista de contatos externos incompleta e uma cadeia de aprovação de comunicação muito lenta para um incidente real.
- Cada função precisa de um substituto nomeado. Se o único responsável estiver inacessível quando o incidente acontecer, o plano não será seguido.
O que é um plano de resposta a incidentes
A maioria das organizações trata a resposta a incidentes como algo para resolver quando o problema aparecer. O resultado é previsível: decisões tomadas sob pressão, por pessoas que nunca enfrentaram esta situação, sem um caminho de escalonamento claro, um protocolo de comunicação definido ou uma sequência de recuperação. A contenção demora mais, evidências se perdem, as comunicações atrasam e os custos sobem.
Um plano de resposta a incidentes documenta o processo que sua organização segue desde a detecção de um incidente de segurança até a restauração, o cumprimento das obrigações legais e a revisão pós-incidente. Ele define quem faz o quê, em que ordem, com que autoridade, e quem informa o quê a quem e quando.
O plano é um documento de pessoas e processos. Antes de qualquer incidente, ele precisa definir quem pode desligar um sistema de produção, quem aprova declarações externas, quem fala com o regulador, quem informa o conselho e quem decide sobre o pagamento de um resgate. As etapas técnicas decorrem dessas respostas. Quando uma resposta real dá errado, a causa costuma ser o processo e a comunicação, e com menos frequência uma lacuna técnica.
A documentação de resposta a incidentes geralmente vem em três camadas. Uma política de resposta a incidentes é curta e define as regras: quem tem a autoridade, o que os funcionários devem reportar e o que a organização exige. O plano, tema deste guia, explica como acionar a resposta, coordená-la, escalar, comunicar e recuperar. Os playbooks trazem as ações para um tipo de incidente, como ransomware ou a queda de um fornecedor. Deixe os procedimentos técnicos detalhados nos playbooks; caso contrário, o plano fica longo demais para usar numa crise.
As seis fases da resposta a incidentes
A Special Publication 800-61 do NIST é a referência mais usada em resposta a incidentes. A Revisão 2 (2012) descreveu um ciclo de vida de quatro fases: Preparação; Detecção e Análise; Contenção, Erradicação e Recuperação; e Atividade Pós-Incidente. A Revisão 3, publicada em abril de 2025, substitui a anterior. Ela enquadra a resposta a incidentes nas seis funções do NIST Cybersecurity Framework 2.0 (Governar, Identificar, Proteger, Detectar, Responder e Recuperar) e trata a preparação e a melhoria como parte da gestão contínua de riscos, e não como fases isoladas.
Para os procedimentos operacionais, a maioria dos profissionais ainda segue as seis etapas abaixo, com a contenção e a erradicação tratadas separadamente. Elas valem para qualquer tipo de incidente, de uma conta de e-mail comprometida a um ataque de ransomware em toda a rede.
Oito etapas para construir o plano
Cada etapa abaixo gera algo concreto. Se uma etapa ainda não tem resultado, essa parte do plano não existe.
Depois de consolidado, o documento do plano costuma seguir esta ordem:
- Objetivo, escopo e responsável pelo plano
- Funções, substitutos e poderes de decisão
- Níveis de gravidade e escalonamento
- A lista de verificação da primeira hora
- Procedimentos de comunicação e notificação, incluindo a matriz de notificação
- Playbooks, ou uma lista deles com onde cada um é mantido
- Prioridades de recuperação e passagem para os planos de recuperação de desastres e de continuidade de negócios
- Critérios de fechamento e revisão pós-incidente
- Anexos: a folha de contatos, o registro de fornecedores críticos, modelos de mensagens e um registro de decisões em branco
O que seu plano deve conter
O plano precisa funcionar sob pressão. Estes são os elementos mínimos de um documento utilizável.
| Nível | Exemplos | Meta de resposta | Quem é informado |
|---|---|---|---|
| P1 Crítico | Ransomware se espalhando; roubo confirmado de dados pessoais ou sensíveis; um serviço crítico inativo; comprometimento de uma conta de administrador ou do sistema de identidade | Imediatamente, a qualquer hora | Líder do incidente, patrocinador executivo, jurídico e encarregado (DPO); conselho informado no mesmo dia |
| P2 Alto | Comprometimento confirmado, mas contido em um sistema ou conta; suspeita de exposição de dados sob investigação; um incidente em um fornecedor crítico que afeta você | Dentro de 1 hora, a qualquer hora | Líder do incidente e líder técnico; encarregado (DPO) se houver dados pessoais envolvidos |
| P3 Médio | Malware capturado em um dispositivo; um clique em phishing com a senha redefinida na hora; uma violação de política sem nenhum sinal de dano | Dentro de 4 horas úteis | Equipe de segurança ou TI; líder do incidente informado |
São metas internas ilustrativas, não prazos legais. A gravidade pode aumentar ou diminuir à medida que as evidências chegam; registre cada alteração e o motivo no registro de decisões. A necessidade de comunicar um regulador é uma avaliação separada, feita contra o critério de cada lei. Um P3 ainda pode exigir comunicação, por exemplo um e-mail com dados de saúde enviado para a pessoa errada.
Uma lista de verificação da primeira hora
A primeira hora define o que vem depois. Trate esta lista como um ponto de partida, não como uma sequência estrita. A contenção pode precisar acontecer nos primeiros minutos, enquanto a preservação das evidências e a avaliação da notificação ocorrem paralelamente, e alguns itens levarão bem mais de uma hora para serem concluídos. Pule o que não se aplica ao incidente à sua frente; cabe ao líder do incidente garantir que cada item aplicável tenha um responsável.
- Abra o registro de decisões: quando o incidente foi detectado, quem o relatou e o que viu
- Nomeie o líder do incidente e confirme quem o substitui
- Atribua um primeiro nível de gravidade, sabendo que pode mudar
- Mova a equipe de resposta para o canal fora de banda se o e-mail, o chat ou o SSO puderem estar comprometidos, e confirme ali a identidade de cada pessoa
- Contenha sem destruir evidências: desconecte os sistemas afetados da rede em vez de desligá-los ou apagá-los
- Preserve logs que são sobrescritos rapidamente, como firewall, VPN, provedor de identidade, auditoria de e-mail e logs de detecção de endpoint
- Proteja os backups: confirme que estão off-line ou imutáveis e corte o acesso de rede ao sistema de backup se ele estiver comprometido
- Ligue para a linha de incidentes da sua seguradora cibernética e para o jurídico; muitas apólices exigem aviso à seguradora antes da contratação de equipes externas
- Se houver dados pessoais envolvidos, registre o momento em que você tomou conhecimento e comece a avaliar se é preciso comunicar
- Informe o patrocinador executivo: o que é conhecido, o que não é, o que foi feito e quando será a próxima atualização
Playbooks por tipo de incidente
O plano cobre a estrutura e os playbooks cobrem os cenários. O plano diz às pessoas qual processo seguir; o playbook diz o que fazer naquele tipo específico de incidente. Escreva playbooks para os tipos de incidente mais relevantes para sua organização. Os cinco abaixo cobrem os cenários mais frequentes.
Ransomware
Indicadores de detecção (mudanças na extensão do arquivo, eventos de acesso em massa a arquivos, notas de resgate aparecendo, atividade de exclusão de backup). Etapas de isolamento imediato: desconecte os sistemas afetados da rede sem desligá-los onde a preservação forense for necessária. Verifique a integridade do backup e o ponto de recuperação antes de continuar. Estabeleça se os dados foram copiados antes da criptografia, porque muitos grupos de ransomware agora também roubam dados, o que altera tanto a avaliação da notificação quanto o risco de extorsão. Restaure num ambiente sabidamente limpo, e não em sistemas que ainda possam conter ferramentas do invasor. Acione o jurídico e a seguradora cibernética antes de qualquer comunicação externa ou decisão de pagamento. Avalie se há obrigação de comunicar (houve acesso a dados pessoais ou criptografia deles?). Estabeleça um canal de comunicação limpo fora do ambiente afetado. A decisão sobre pagar o resgate deve seguir um processo estruturado, com o jurídico, a seguradora e a liderança, e não ser tomada às pressas.
Comprometimento de e-mail corporativo (BEC) e desvio de pagamento
Se for descoberta uma instrução de pagamento fraudulenta, entre em contato imediatamente com o banco remetente. Muitos bancos têm procedimentos de bloqueio e devolução em caso de fraude que podem recuperar o dinheiro em poucas horas, se acionados antes que a conta de destino seja esvaziada. Se o pagamento foi por Pix, peça ao seu banco que acione o Mecanismo Especial de Devolução (MED). Preserve todas as evidências de e-mail, incluindo cabeçalhos, antes de redefinir contas. Em seguida, redefina a senha, revogue as sessões ativas e atualize os tokens e verifique os métodos MFA registrados, porque os invasores geralmente adicionam os seus próprios; onde houver suspeita de comprometimento, remova-os e peça ao usuário que cadastre o MFA de novo. Identifique se outras contas estavam envolvidas, se foram definidas regras de encaminhamento ou de caixa de entrada e se algum aplicativo OAuth recebeu acesso. Avise as partes afetadas, como fornecedores ou clientes, se os dados ou pagamentos delas estiverem envolvidos.
Incidente com dados pessoais
Um incidente com dados pessoais vai além do roubo. Inclui dados pessoais enviados para a pessoa errada, um laptop perdido ou roubado, registros alterados ou excluídos sem autoridade e dados indisponíveis, por exemplo, quando o ransomware criptografa a única cópia. Levante os dados afetados: quais categorias, quantos titulares, em que período. Avalie o risco para os titulares e decida se precisa comunicar uma autoridade de proteção de dados, e qual. De acordo com a LGPD, a comunicação deve chegar à ANPD no prazo de três dias úteis após o conhecimento de que o incidente afetou dados pessoais; outros países têm prazos diferentes, resumidos abaixo. Quando a comunicação é obrigatória, os titulares afetados devem ser avisados no mesmo prazo. Preserve a cadeia de custódia das evidências. Documente a decisão mesmo quando concluir que a comunicação não é necessária: a Resolução CD/ANPD nº 15/2024 exige o registro de todos os incidentes, inclusive os não comunicados.
Comprometimento de conta
Antes de retornar a conta para uso, redefina a senha, revogue todas as sessões ativas e atualize os tokens e remova e recadastre os métodos de MFA quando houver suspeita de comprometimento. Uma redefinição de senha por si só pode deixar as sessões existentes funcionando. Audite todas as ações realizadas pela conta comprometida durante o período do comprometimento: e-mails enviados, arquivos acessados, permissões alteradas, regras criadas, aplicativos autorizados. Verifique regras de encaminhamento de e-mail, novas contas de administrador e atribuições de funções privilegiadas, concessões de consentimento OAuth para aplicativos conectados, alterações nas configurações de federação ou domínios confiáveis e alterações nas políticas de autenticação ou acesso condicional. O ponto mais esquecido na recuperação é a conta comprometida que foi usada para criar acesso persistente em outro lugar.
Incidente ou queda de um fornecedor
Alguns dos incidentes mais disruptivos começam fora da sua rede. Seu provedor de serviços gerenciados (MSP) é invadido, uma plataforma de nuvem fica fora do ar por dois dias ou uma atualização defeituosa de um fornecedor de segurança derruba seus notebooks, como a atualização CrowdStrike fez com milhões de máquinas Windows em 19 de julho de 2024. Quando o ransomware atingiu o serviço de patologia Synnovis em junho de 2024, os hospitais do NHS em Londres que dependiam dele adiaram milhares de compromissos e operações. Você não pode investigar sistemas que não são seus e talvez nunca veja os logs deles. Por isso, este playbook trata das decisões que estão nas suas mãos. Para cada fornecedor crítico, ele responde a três perguntas: como saberemos, o que desligamos e como continuamos operando?
Confirme o incidente por um contato que você já tem, e não por um número ou link do próprio alerta; invasores se passam por fornecedores. Depois, descubra se o fornecedor foi invadido ou só está fora do ar, porque cada caso pede ações diferentes.
Se o fornecedor foi invadido e tem acesso ao seu ambiente, decida cedo se vai cortar esse acesso. Desative as ferramentas de acesso remoto e as contas de VPN dele, suspenda integrações e conexões de API e troque as senhas ou chaves que ele tenha. A ferramenta de gerenciamento remoto de um MSP alcança todas as máquinas que ele gerencia, por isso trate um MSP invadido como uma possível invasão da sua própria rede. Verifique quais dados o fornecedor guarda ou trata para você e se há dados pessoais entre eles.
Se o fornecedor estiver fora do ar, mas não houver sinal de comprometimento, cortar seu acesso traz pouco ganho e pode retardar a recuperação dele e a sua. Mantenha a conexão sob observação e passe para a solução alternativa combinada (um processo manual, um segundo fornecedor ou um serviço reduzido). Em ambos os casos, diga aos funcionários o que muda para eles.
Pergunte ao fornecedor, por escrito, o que aconteceu e quando, quais dos seus sistemas e dados foram afetados e quais indicadores de comprometimento você deve procurar. Registre cada solicitação e cada resposta. Pela LGPD, comunicar a ANPD é dever seu, como controlador, e não do fornecedor, e seus três dias úteis são contados a partir do momento em que você toma conhecimento de que o incidente afetou dados pessoais. O aviso do fornecedor costuma iniciar essa contagem, mas uma notícia, a reclamação de um cliente ou o seu próprio monitoramento podem iniciá-la antes, então avalie na hora e registre quando e como você soube. Como as regras impõem essa obrigação a você, seu contrato deve exigir que o fornecedor avise você rapidamente. O GDPR europeu divide a obrigação da mesma forma. Se o fornecedor demorar a dar detalhes, comunique dentro do prazo o que já sabe e complemente depois. Nosso guia de segurança da cadeia de suprimentos trata das cláusulas contratuais e dos controles de acesso que facilitam este playbook.
Se a sua empresa é o fornecedor, vale o inverso. Seus contratos com clientes e acordos de tratamento de dados podem fixar prazos de aviso mais curtos do que os de qualquer regulador. Coloque no plano esses prazos, os contatos do cliente e a pessoa que decide o que dizer aos clientes.
Obrigações de comunicação a reguladores, titulares e clientes
As obrigações dependem de onde você opera, de onde moram as pessoas afetadas e do seu setor. Um incidente que atinge clientes em vários países pode disparar vários prazos ao mesmo tempo, cada um com seu regulador, seu critério e seu prazo. Conter o incidente não elimina nenhuma dessas obrigações. A matriz de notificação da etapa 3 lista cada regime que se aplica a você e responde a seis perguntas:
- Quais leis, reguladores e contratos se aplicam, considerando onde você opera, de quem são os dados e em que setor você atua?
- Que tipo de incidente é: um incidente com dados pessoais, a interrupção de um serviço regulado, ou os dois?
- O incidente atinge o critério do regime? A maioria só exige comunicação acima de certo nível de risco ou impacto.
- Quando você tomou conhecimento? A maioria dos prazos conta a partir desse momento, então registre-o.
- Quem precisa ser informado (um regulador, os titulares, clientes, a seguradora), quem decide, quem comunica e por qual canal?
- Qual é o prazo, e que complementos ou relatórios são exigidos depois da primeira comunicação?
As regras brasileiras abaixo mostram como isso funciona na prática. Em seguida, há um resumo para outras jurisdições importantes.
O controlador deve comunicar à ANPD e aos titulares o incidente de segurança que possa causar risco ou dano relevante (art. 48 da LGPD e Resolução CD/ANPD nº 15/2024). Pela resolução, isso acontece quando o incidente pode afetar significativamente interesses e direitos fundamentais dos titulares e envolve pelo menos um destes fatores: dados sensíveis; dados de crianças, adolescentes ou idosos; dados financeiros; dados de autenticação em sistemas; dados protegidos por sigilo legal, judicial ou profissional; ou dados em larga escala.
O prazo é de três dias úteis a partir do conhecimento de que o incidente afetou dados pessoais, e os titulares devem ser avisados no mesmo prazo. A comunicação à ANPD é feita pelo formulário eletrônico da autoridade, por meio do encarregado, e pode ser complementada em até 20 dias úteis. Para agentes de pequeno porte, os prazos contam em dobro. Registre todos os incidentes, inclusive os que você decidir não comunicar, com a avaliação feita, e guarde o registro por pelo menos cinco anos.
Instituições autorizadas a funcionar pelo Banco Central devem comunicar ao BC, de forma tempestiva, os incidentes relevantes (Resoluções CMN nº 4.893/2021 e BCB nº 85/2021, atualizadas pelas Resoluções CMN nº 5.274/2025 e BCB nº 538/2025). O prazo interno e os critérios de relevância ficam na política de segurança cibernética da instituição, e o registro do incidente fica disponível para a fiscalização. Se a sua empresa presta serviços a bancos, o contrato provavelmente exige que você avise a instituição rapidamente; nosso artigo sobre o que a CMN 5.274 e a BCB 538 exigem dos fornecedores explica por quê.
A notificação ao CERT.br é voluntária, mas ajuda na coordenação quando o ataque envolve outras redes. Se houver crime, como extorsão ou fraude, registre um boletim de ocorrência.
Fora do Brasil
Os principais regimes em outros países, em resumo. Cada um tem seu próprio critério de notificação, e alguns valem só para certos setores ou portes de empresa. Nosso artigo sobre prazos de notificação de incidentes por país detalha cada regime, com links para as fontes oficiais.
| Regime | Quem comunica a quem | Prazo |
|---|---|---|
| União Europeia (GDPR) | Controlador à autoridade de proteção de dados; titulares quando o risco é alto | 72 horas após a ciência, quando viável |
| União Europeia (NIS2) | Entidades essenciais e importantes ao CSIRT ou à autoridade competente | Alerta inicial em 24 horas, notificação em 72 horas e relatório final em um mês |
| União Europeia (DORA) | Entidades financeiras à autoridade competente, em incidentes graves de TIC | Notificação inicial em 4 horas após a classificação como grave e no máximo 24 horas após a ciência; relatório intermediário em 72 horas; relatório final em um mês |
| Reino Unido (UK GDPR) | Controlador ao ICO; titulares quando o risco é alto | 72 horas após a ciência, quando viável |
| Reino Unido (NIS Regulations) | Operadores de serviços essenciais e provedores de serviços digitais à autoridade competente | 72 horas após a ciência |
| EUA (estados) | Organizações aos residentes afetados e, muitas vezes, ao procurador-geral do estado | Varia por estado; Colorado, Flórida e Washington exigem 30 dias |
| EUA (HIPAA) | Entidades de saúde aos titulares, ao HHS e, acima de 500 residentes de um estado, à imprensa | 60 dias após a descoberta; casos com menos de 500 pessoas vão ao HHS uma vez por ano |
| EUA (SEC) | Empresas listadas aos investidores, pelo Form 8-K, em incidentes materiais | Quatro dias úteis após concluir que o incidente é material; essa conclusão deve vir sem demora injustificada |
| Austrália | Organizações ao OAIC e aos titulares; empresas com faturamento a partir de A$3 milhões ao ASD em caso de pagamento de resgate | Incidentes com dados: assim que possível; pagamentos de resgate: 72 horas |
| Índia | A maioria das organizações ao CERT-In, nos tipos de incidente listados | Seis horas após a ciência |
| Canadá | Organizações privadas ao Privacy Commissioner e aos titulares | Assim que possível, quando há risco real de dano significativo |
Se você opera em vários países da UE, defina com antecedência qual autoridade é a principal para você e registre isso no plano. Se opera nos EUA, considere também comunicar ataques à CISA e ao IC3 do FBI e verifique se o seu setor tem regras próprias.
Muitas organizações adiam a comunicação enquanto tentam entender toda a extensão do incidente. Pela LGPD, os três dias úteis contam a partir do momento em que você sabe que o incidente afetou dados pessoais, e não de quando consegue confirmar o tamanho do problema. A ANPD não exige o quadro completo na primeira comunicação: comunique no prazo com o que você sabe e complemente em até 20 dias úteis, à medida que a investigação avança.
Guarde o plano onde ele continue acessível
Este ponto aparece com frequência nas revisões pós-incidente e quase nunca é tratado antes: se o seu plano de resposta a incidentes estiver no SharePoint, no seu sistema de e-mail ou em uma unidade de rede, ele poderá estar indisponível exatamente quando você precisar dele.
Um ataque de ransomware que criptografa servidores de arquivos e unidades sincronizadas na nuvem também criptografa o plano de resposta a incidentes armazenado neles. Guarde uma cópia atualizada off-line, impressa, num local que todos da equipe de resposta conheçam. Inclua a lista de contatos externos na versão impressa. Uma opção é guardá-la junto com a documentação do seguro cibernético.
Como testar o plano
Um plano não testado é um conjunto de suposições. Há três níveis de teste, cada um adequado a um estágio de maturidade do programa.
Os exercícios de tabletop tendem a expor as mesmas lacunas: o caminho de escalonamento não é claro quando o contato principal não está disponível, a lista de contatos externos está incompleta ou tem números desatualizados, a cadeia de aprovação de comunicação tem muitas etapas para um incidente rápido e os membros da equipe não sabem onde o plano está armazenado.
Execute pelo menos um exercício em que o incidente começa em um fornecedor: seu MSP avisa de uma invasão numa sexta-feira à noite ou sua plataforma de nuvem principal fica indisponível por dois dias. A maioria dos planos nunca passou por esse teste. O exercício mostra quem tem autoridade para cortar o acesso de um fornecedor, quanto tempo realmente dura a solução alternativa manual e o que você diz aos clientes antes que o fornecedor lhe dê as respostas.
Meça cada exercício em relação às próprias metas do plano: quanto tempo levou para declarar o incidente, para chegar aos tomadores de decisão, para decidir sobre a notificação e para colocar o canal fora de banda em funcionamento. Registre cada lacuna como uma ação corretiva com um responsável e um prazo, e verifique essas ações no início do próximo exercício.
Erros comuns
Uma única pessoa para cada função. Se o responsável nomeado estiver inacessível durante o incidente, a equipe passa a improvisar. Cada função precisa de um substituto, e o substituto precisa saber que é o substituto.
O plano termina na contenção. Muitas organizações documentam da detecção até a contenção e tratam a recuperação como óbvia. A sequência de recuperação, os requisitos de monitoramento durante a recuperação e as condições para o retorno dos sistemas à produção precisam ser explícitos. A recuperação sem monitoramento é um convite à reinfecção.
Sem modelos de comunicação. Elaborar comunicações de clientes, fornecedores ou mídia durante um incidente ativo, sob escrutínio legal e pressão de tempo, produz resultados inconsistentes e juridicamente problemáticos. Modelos prontos, revisados pelo jurídico, reduzem o tempo e os riscos envolvidos.
O plano nunca foi testado. Um plano escrito uma vez e arquivado reflete o ambiente tal como era quando foi escrito. Pessoas, sistemas, fornecedores e obrigações regulatórias mudam. Sem teste, você não sabe como a equipe vai se sair. Sem atualização, o plano descreve uma organização que já não existe. Nomeie um responsável pelo plano, revise-o pelo menos uma vez por ano e atualize-o após grandes alterações no sistema ou no fornecedor, aquisições, alterações no escopo regulatório e todos os exercícios ou incidentes reais.
Backups nunca testados. A parte mais importante da recuperação de ransomware é um backup que pode ser restaurado sob pressão de tempo para um estado utilizável. Muitas organizações têm backups que nunca foram restaurados. Até que você restaure um backup em condições realistas, você não sabe se funcionará.
Contar que o fornecedor vai avisar. Muitos contratos de fornecedores dizem pouco sobre aviso de incidentes, e um fornecedor no meio de seu próprio incidente demora a compartilhar detalhes. Verifique a cláusula de notificação de cada fornecedor crítico, combine um contato nomeado de cada lado e planeje agir com base em informações parciais. Se você esperar pelo relatório completo do fornecedor, seus três dias úteis podem acabar antes.
