NIST SP 800-34 (Contingency Planning) Guia — continuidade de TI

39 controles, organizados por grupo, com resumo em português.

Guia do NIST para planejamento de contingência de sistemas de informação, organizado nos 7 passos oficiais do processo (política, análise de impacto no negócio, controles preventivos, estratégias, desenvolvimento do plano, teste/treinamento/exercícios e manutenção). Complementa a ISO 22301: enquanto a ISO cobre continuidade de negócios no nível organizacional, o SP 800-34 é focado no Information System Contingency Plan (ISCP) — o ângulo técnico e tático de recuperação de sistemas.

Fonte oficial · A cor indica o perfil em que cada controle entra: Básico Intermediário Avançado.

Texto oficial (obra do governo dos EUA, domínio público, Rev. 1 de 2010, sem revisão mais nova). Onde o documento tem número de seção oficial, ele é citado na descrição; onde só há lista solta (Passos 1, 3 e 7), a numeração dos itens é editorial da InfoCuestaSec, não do NIST. Divisão em perfis é didática.

P1 Passo 1 — Política de Planejamento de Contingência

P1.1
A política de contingência define papéis e responsabilidades claros. Numa emergência real, não é hora de descobrir quem decide o quê — papéis claros na política evitam essa confusão.
Básico
P1.2
A política de contingência define o escopo (quais sistemas são cobertos). Sem escopo definido, sistemas críticos podem ficar de fora do plano sem que ninguém perceba até o incidente acontecer.
Básico
P1.3
A política define os requisitos de recursos (orçamento, pessoal, ferramentas) para contingência. Um plano sem orçamento e recurso alocado é só uma intenção — não sobrevive ao primeiro teste real.
Intermediário
P1.4
A política define os requisitos de treinamento em contingência. Plano bem escrito e equipe sem treinamento é a combinação clássica que falha na hora da execução real.
Intermediário
P1.5
A política define o cronograma de exercícios e testes do plano. Sem cronograma definido, testes de contingência tendem a nunca acontecer — sempre há algo "mais urgente".
Intermediário
P1.6
A política define o cronograma de manutenção e revisão do plano. Um plano nunca revisado fica desatualizado em relação a sistemas, contatos e riscos que mudaram desde a última versão.
Intermediário
P1.7
A política define a frequência mínima de backup exigida. Backup infrequente demais significa que, na hora de recuperar, o dado disponível já está velho demais para ser útil.
Intermediário

P2 Passo 2 — Análise de Impacto no Negócio (BIA)

P2.1
São determinados os processos de negócio e a criticidade de recuperação de cada sistema (§3.2). Sem saber quais sistemas sustentam quais processos de negócio, não dá para priorizar recurso de recuperação.
Básico
P2.2
São identificados e estimados o impacto da interrupção e o tempo de indisponibilidade tolerável (MTD/RTO/RPO). MTD/RTO/RPO são os números que decidem quanto investir em cada estratégia — sem eles, a decisão vira chute.
Básico
P2.3
São identificados os requisitos de recursos necessários para a recuperação de cada sistema (§3.2). Levantar recurso necessário DEPOIS de um incidente é tarde demais — o BIA existe pra isso ser feito antes.
Intermediário
P2.4
São definidas as prioridades de recuperação entre os recursos do sistema (§3.2). Recurso de recuperação é sempre limitado — sem prioridade clara, tudo compete pela mesma atenção na hora da crise.
Intermediário

P3 Passo 3 — Controles Preventivos

P3.1
Controles preventivos são identificados para cada sistema (ex.: nobreak, gerador, supressão de incêndio, backup frequente). Prevenir é sempre mais barato que recuperar — identificar o controle certo evita que o incidente aconteça.
Básico
P3.2
Os controles preventivos identificados são implementados de fato. Controle identificado e nunca implementado é só um item de lista, não uma proteção real.
Intermediário
P3.3
Os controles preventivos implementados são mantidos e testados periodicamente. Um nobreak ou gerador que nunca é testado pode falhar justamente na hora em que mais precisa funcionar.
Intermediário

P4 Passo 4 — Estratégias de Contingência

P4.1
A estratégia de backup e recuperação de dados está definida (§3.4.1). Sem estratégia de backup clara, a recuperação de dados vira improviso no meio do incidente.
Básico
P4.2
Os métodos de backup e o armazenamento fora do site (offsite) estão definidos (§3.4.2). Backup guardado no mesmo local do sistema original não protege contra desastre físico (incêndio, enchente) que afete os dois juntos.
Intermediário
P4.3
O tipo de site alternativo (frio, morno, quente, móvel ou espelhado) está definido conforme a criticidade do sistema (§3.4.3). O tipo de site alternativo (frio a espelhado) define o tempo real de recuperação — escolher o tipo errado custa caro ou é lento demais.
Intermediário
P4.4
A estratégia de substituição de equipamentos em caso de perda está definida (§3.4.4). Sem plano de substituição de equipamento, um hardware perdido pode travar a recuperação por semanas, esperando compra emergencial.
Intermediário
P4.5
O custo de cada estratégia de contingência é considerado formalmente na escolha (§3.4.5). A estratégia mais robusta nem sempre é a mais adequada — custo tem que entrar na decisão, senão o plano fica inviável na prática.
Avançado
P4.6
Papéis e responsabilidades específicos da estratégia de contingência escolhida estão definidos (§3.4.6). Cada estratégia de contingência tem sua própria logística — sem papel definido, ninguém sabe quem executa o quê.
Intermediário

P5 Passo 5 — Desenvolvimento do Plano (ISCP)

P5.1
As informações de apoio do plano (visão geral do sistema, conceito de operações) estão documentadas (§4.1). Sem contexto documentado (o que o sistema faz, como opera normalmente), quem executa o plano numa crise real não tem referência.
Básico
P5.2
Os critérios e o procedimento de ativação do plano estão definidos (§4.2.1). Sem critério claro de quando ativar o plano, a decisão de acionar (ou não) fica em cima da hora, sob pressão.
Básico
P5.3
Os procedimentos de notificação da fase de ativação estão definidos (§4.2.2). Notificação lenta ou mal definida atrasa toda a cadeia de resposta que depende dela.
Intermediário
P5.4
O processo de avaliação de danos (outage assessment) na ativação está definido (§4.2.3). Sem avaliar o dano real primeiro, a resposta pode ser desproporcional (de menos ou de mais) ao problema de verdade.
Intermediário
P5.5
A sequência das atividades de recuperação está definida (§4.3.1). Recuperar componentes fora de ordem pode desperdiçar esforço ou até impedir que o sistema volte a funcionar de forma consistente.
Intermediário
P5.6
Os procedimentos de recuperação passo a passo estão documentados (§4.3.2). Procedimento vago ("restaurar o sistema") não é executável sob pressão — precisa ser passo a passo, testável.
Intermediário
P5.7
Os procedimentos de escalonamento e notificação durante a recuperação estão definidos (§4.3.3). Sem critério de escalonamento, um problema que cresce durante a recuperação pode não chegar a quem precisa decidir a tempo.
Avançado
P5.8
A fase de reconstituição (validar o sistema e retomar operações normais) está definida (§4.4). Voltar rápido demais ao normal, sem validar, pode reintroduzir o mesmo problema que causou a interrupção.
Intermediário
P5.9
Os apêndices do plano (contatos, procedimentos técnicos, diagramas) estão mantidos atualizados (§4.5). Apêndice desatualizado (contato errado, procedimento antigo) é onde planos bem escritos falham na hora H.
Avançado

P6 Passo 6 — Teste, Treinamento e Exercícios (TT&E)

P6.1
O plano de contingência é testado periodicamente para validar sua eficácia (§3.5.1). Um plano nunca testado tende a falhar de formas que só aparecem na prática, não na teoria.
Básico
P6.2
A equipe é treinada nos seus papéis e responsabilidades dentro do plano (§3.5.2). Treinamento é o que transforma o plano escrito em ação coordenada de verdade durante um incidente.
Intermediário
P6.3
Exercícios (tabletop ou funcionais) são realizados para simular a execução do plano (§3.5.3). Exercício revela lacunas (comunicação, dependência esquecida) que a leitura do documento sozinha nunca mostraria.
Intermediário
P6.4
Existe um programa formal de TT&E, com escopo, tipos de exercício e frequência definidos (§3.5.4). Sem programa formal, teste e treinamento viram eventos esporádicos em vez de prática recorrente e evolutiva.
Avançado

P7 Passo 7 — Manutenção do Plano

P7.1
Os requisitos operacionais e de segurança do plano são revisados periodicamente. Requisito de segurança e operação muda com o tempo — plano parado no tempo protege contra um cenário que já não existe.
Básico
P7.2
Os procedimentos técnicos do plano são revisados e atualizados. Procedimento técnico desatualizado (versão de sistema errada, passo obsoleto) trava a recuperação no momento crítico.
Intermediário
P7.3
Os contatos da equipe de contingência e dos fornecedores são mantidos atualizados. Contato de fornecedor ou da equipe desatualizado transforma o primeiro passo da resposta numa perda de tempo evitável.
Intermediário
P7.4
Os requisitos do site alternativo e os contratos associados são revisados. Um contrato de site alternativo vencido ou não renovado descobre-se, no pior momento possível, no meio do incidente.
Intermediário
P7.5
Acordos de apoio (MOUs, SLAs) relacionados à contingência são revisados. Acordo de apoio (MOU/SLA) que não é revisado pode não cobrir mais o cenário real de dependência da organização.
Intermediário
P7.6
O escopo dos testes e o alinhamento do plano com outros planos relacionados (BCP, DRP, COOP) são revisados. Planos que deveriam se complementar (BCP, DRP, COOP, ISCP) e não estão alinhados podem se contradizer numa crise real.
Avançado