A ISO decidiu revisar a ISO 22301:2019, e a mudança interessa diretamente à defesa. A norma internacional que define os requisitos do BCMS — o sistema de gestão de continuidade de negócios — foi marcada para revisão em dezembro de 2025, e a edição 3 da norma já circula em comitê, com o período de comentários encerrado em 10 de maio de 2026. Quem é afetado: organizações certificadas na norma, fornecedores obrigados por contrato a provar continuidade e times de segurança responsáveis por manter serviços no ar durante ataques. A ação prioritária é tirar a continuidade da prateleira: mapear serviços críticos, dar dono e métrica a cada elemento do programa e revisar o conjunto em ciclo fixo, porque é isso que a norma cobra — e a nova edição tende a cobrar com mais rigor.
O que é um BCMS
O BCMS (Business Continuity Management System) trata a continuidade como sistema de gestão, no mesmo molde da ISO 27001 para segurança da informação. A descrição oficial da norma diz que ela fornece uma estrutura para a organização planejar, estabelecer, implementar, operar, monitorar, revisar, manter e melhorar continuamente um sistema documentado, com três objetivos explícitos: proteger contra incidentes disruptivos, reduzir a probabilidade de ocorrência e garantir a recuperação. A edição vigente foi publicada em outubro de 2019, tem 21 páginas e é revisada a cada ciclo de cinco anos — ciclo que agora está em curso.
A diferença para um plano de recuperação tradicional está no escopo e na disciplina. Um runbook de desastre descreve como restaurar um sistema; o BCMS exige entender o impacto sobre o negócio, definir estratégias de continuidade, exercitar, comunicar e melhorar o conjunto a cada rodada. Para o time defensivo, isso muda a pergunta central: não é apenas como recuperar o servidor, e sim qual capacidade mínima o negócio precisa entregar durante o incidente — e por quanto tempo a operação suporta rodar sem ela.
Por que a norma muda
A revisão tem cronograma público na própria página da norma. A decisão de revisar ficou registrada em 5 de dezembro de 2025, o novo projeto foi aprovado na mesma data, o comitê draft da edição 3 foi registrado em 12 de março de 2026 e a consulta de comentários fechou em 10 de maio de 2026. O trabalho corre no ISO/TC 292, o comitê técnico de segurança e resiliência, e o documento segue em desenvolvimento, sem data de publicação final. Certificações vigentes continuam auditadas contra a edição de 2019 enquanto o processo avança pelos estágios de enquiry e aprovação.
Três razões tornam a revisão relevante para quem cuida de segurança. Primeira: cenários cibernéticos dominaram as interrupções mais custosas dos últimos anos, e a norma precisa refletir um adversário que trava a operação inteira, não só desastres físicos. Segunda: um número crescente de contratos públicos e de fornecimento exige prova de continuidade, e a norma é a referência de auditoria dessa prova. Terceira: organizações já certificadas em ISO 27001 podem integrar os dois sistemas de gestão, reduzindo custo de auditoria — e a revisão tende a facilitar essa integração.
O núcleo da exigência
O resumo oficial do comitê draft da edição 3 mostra o que permanece como núcleo: requisitos para implementar, manter e melhorar um sistema de gestão que proteja contra interrupções, reduza a probabilidade de ocorrência, prepare a organização, responda e recupere quando elas surgirem. Os requisitos são genéricos e aplicáveis a organizações de qualquer tipo, tamanho e natureza; a extensão da aplicação depende do ambiente operacional e da complexidade de cada uma. O documento também mantém o público explícito: organizações que precisam continuar entregando produtos e serviços em uma capacidade predefinida e aceitável durante uma interrupção.
Para a defesa, três traduções importam. Capacidade predefinida e aceitável significa que o negócio — não o TI — decide qual nível degradado é tolerável por serviço. Reduzir a probabilidade liga a continuidade a controles preventivos, de backup imutável a segregação de acessos. Responder e recuperar liga o sistema ao plano de resposta a incidentes e ao plano de recuperação de desastre, que precisam conversar em vez de existir em silos. Quem busca orientação de aplicação encontra ajuda na norma irmã ISO 22313:2020, publicada pela própria ISO para orientar o uso da 22301.
Contingência na prática
O lado técnico do problema tem referência complementar no guia de contingência do NIST, o SP 800-34 Rev. 1. A publicação ajuda organizações a entender o propósito, o processo e o formato do planejamento de contingência de sistemas de informação por meio de diretrizes práticas, e o NIST distribui modelos prontos junto ao guia: um template de análise de impacto de negócio e planos de contingência por nível de impacto — baixo, moderado e alto. O guia também posiciona o plano de contingência em relação ao plano de resposta a incidentes e ao plano de recuperação de desastre, o que evita sobreposição de responsabilidades durante a crise.
Uma forma de fechar a lacuna entre norma e operação é mapear cada elemento do BCMS a uma entrega concreta do time defensivo:
| Elemento do BCMS | Tradução cibernética | Evidência mínima de que existe |
|---|---|---|
| Análise de impacto | Lista de serviços críticos com capacidade mínima e tolerância de interrupção por serviço | Documento aprovado pelo dono do negócio, não pelo TI |
| Estratégia de continuidade | Backup imutável, ambiente alternativo e dependências mapeadas | Teste de recuperação com data e resultado registrados |
| Plano de contingência | Runbook por serviço com passos, papéis e critério de ativação | Versão revisada no último ciclo, acessível offline |
| Exercícios | Tabletop e teste de recuperação periódicos | Relatório de cada exercício com lições aplicadas |
| Comunicação de crise | Canal fora de banda e declarações preliminares aprovadas | Teste de ativação do canal com a lista real de participantes |
A última linha da tabela costuma ser a mais esquecida. Coordenar a crise por canal comprometido entrega o roteiro da contenção ao atacante — o guia sobre comunicação fora de banda detalha como provisionar e testar essa alternativa antes do incidente. No BCMS, esse canal deixa de ser improviso de TI e passa a ser controle gerido, com dono, lista de participantes e critério de ativação escritos.
Como preparar a transição
- P1 — Inventário de serviços críticos: listar os serviços que sustentam a entrega ao cliente, com a capacidade mínima aceitável e a tolerância de interrupção definidas pelo negócio para cada um.
- P1 — Dono e ciclo de revisão: nomear formalmente o responsável pelo programa de continuidade e fixar o calendário de revisão de indicadores, planos e contatos.
- P1 — Análise de lacunas: comparar o programa atual com os requisitos da edição vigente da norma e registrar o que falta em evidência, não em intenção.
- P2 — Exercício cibernético integrado: rodar um tabletop cujo cenário seja um ataque que degrada serviço crítico, testando a decisão de capacidade mínima junto à contenção técnica.
- P2 — Integração com risco e seguro: incluir a exposição de continuidade no registro de riscos e conferir o que a apólice realmente paga em cenário de ataque — as exclusões decidem o caixa da recuperação, como mostra a análise sobre seguro cibernético.
- P2 — Monitorar a edição final: acompanhar a publicação da edição 3 no comitê e replanejar o escopo de certificação quando o texto final estiver disponível.
A meta não é reescrever a norma, e sim eliminar a surpresa. Organizações que já medem capacidade mínima por serviço, testam recuperação em ciclo e exercitam comunicação de crise vão absorver a nova edição como ajuste de escopo. Quem ainda trata continuidade como documento assinado uma vez vai descobrir a distância entre plano e operação na frente do auditor — ou do atacante.