NIST SP 800-61r3: a resposta a incidentes já não cabe num plano isolado
A revisão 3 substituiu o guia de 2012 e organiza a resposta como um perfil do CSF 2.0. Governar, identificar e proteger preparam; detetar, responder e recuperar executam — com aprendizagem a regressar ao sistema de risco.
- Natureza
- Perfil operacional baseado no NIST SP 800-61r3 e CSF 2.0
- Quem deve ler
- Segurança, tecnologia, continuidade, jurídico, comunicação e direção
- Publicado e verificado
- 4 de agosto de 2026
- Limite
- Adapte a requisitos legais, setoriais, contratuais e de notificação aplicáveis

Em resumo
O ganho prático não é renomear as fases. É atribuir decisões, evidência e métricas às seis funções do CSF 2.0 e garantir que passam de uma para a outra. O board define apetite e autoridade; inventário e dependências determinam o que proteger primeiro; telemetria cria sinais acionáveis; resposta contém e comunica; recuperação restaura por prioridade de missão. O exercício proposto testa um incidente através desse percurso e mede quatro tempos: deteção, decisão, contenção e recuperação validada.
- SP 800-61r3 foi finalizada em abril de 2025 e substitui a revisão 2.
- As seis funções do CSF 2.0 desempenham papéis na resposta; não existe uma fronteira limpa entre ‘antes’ e ‘durante’.
- O playbook deve ligar cada decisão a autoridade, informação de entrada, evidência de saída e condição de escalada.
- Recuperar não é apenas pôr o serviço online: é validar integridade, prioridade de missão e risco residual.
A resposta é um ciclo de risco com seis funções e dois ritmos
Govern, Identify e Protect operam continuamente: definem autoridade, prioridades, ativos, dependências, salvaguardas e preparação. Detect, Respond e Recover aceleram quando um evento cumpre o critério de incidente. As lições regressam ao primeiro grupo como mudança de risco, controlo e investimento.
Mantenha um ritmo operacional para restaurar e um ritmo de governação para decidir impacto, tolerância e comunicação. Misturá-los produz reuniões grandes sem decisões; separá-los sem interface produz decisões executivas baseadas em dados atrasados.
Fluxo de decisão entre as seis funções
- GOVERNFixar autoridade e tolerância
Definir quem declara, contém, comunica, aceita risco residual e encerra.
- IDENTIFYPriorizar missão e dependências
Ligar ativos, dados, terceiros, pessoas e impacto a serviços essenciais.
- PROTECTPreparar modos seguros
Aplicar salvaguardas, acessos de emergência, backups, canais e exercícios.
- DETECTConverter sinal em incidente
Preservar origem, tempo, confiança, alcance e critérios de declaração.
- RESPONDConter e coordenar
Tomar decisões reversíveis, preservar prova e comunicar com cadência.
- RECOVERRestaurar e validar
Recuperar por prioridade, testar integridade e devolver lições ao risco.
A matriz revela interfaces que um playbook narrativo costuma esconder
Para cada função, defina uma decisão observável e a evidência que permite entregá-la à função seguinte. Se a equipa não consegue indicar o artefacto de saída, o procedimento ainda depende de conversa e memória.
Função, decisão, evidência e métrica
| Função | Decisão | Evidência de saída | Métrica útil |
|---|---|---|---|
| Govern | Quem pode aceitar e escalar? | Carta de autoridade e contactos | Tempo até decisão autorizada |
| Identify | Que serviço vem primeiro? | Mapa ativo–dependência–impacto | Cobertura de serviços críticos |
| Protect | Que modo degradado é seguro? | Controlo, backup e teste recente | Taxa de teste bem-sucedido |
| Detect | Isto é incidente? | Sinal, contexto, confiança e timestamp | Tempo sinal–declaração |
| Respond | Conter onde e com que efeito? | Decisão, ação e estado confirmado | Tempo declaração–contenção |
| Recover | Pode regressar à produção? | Integridade, reconciliação e risco residual | Tempo até recuperação validada |
O exercício deve atravessar a organização e terminar com uma mudança verificável
Use um cenário que combine credenciais comprometidas, terceiro indisponível e dados potencialmente alterados. Introduza conflito entre recuperação rápida e necessidade de preservar evidência. A equipa passa quando toma decisões no nível certo e consegue demonstrar o estado alcançado.
Depois, selecione no máximo três mudanças, cada uma com dono, prazo e teste. Uma lista longa de lições sem verificação cria arquivo, não resiliência.
- Testar canais alternativos e diretório de contactos fora do ambiente afetado.
- Exigir confirmação técnica do efeito de contenção.
- Validar dados e transações antes de declarar recuperação.
- Repetir o cenário após a correção e comparar os quatro tempos.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01NIST SP 800-61 Rev. 3 — Incident ResponseNIST CSRC · CY-NISTCSRC
- 02NIST Revises SP 800-61NIST CSRC · CY-NISTCSRC
- 03Incident Response project publicationsNIST CSRC · CY-NISTCSRC
- 04NIST Cybersecurity Framework 2.0NIST CSRC · CY-NISTCSRC
- 05NIST SP 800-184 — Cybersecurity Event RecoveryNIST CSRC · CY-NISTCSRC
- 06NIST SP 1299 — CSF 2.0 Resource and Overview GuideNIST CSRC · CY-NISTCSRC
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.

Comentários
A carregar a conversa.