Quase toda organização tem backups. Pouquíssimas sabem quanto tempo levariam de fato para retomar as operações depois de uma interrupção grave, ou que processos recuperar primeiro. Essa lacuna, entre ter backups e ter continuidade, é exatamente o que a ISO 22301 coloca em ordem. Neste artigo explico o que a norma exige, como fazer uma análise de impacto que sirva de verdade para decidir, o que RTO e RPO significam quando há dinheiro em jogo, por que um plano nunca testado não conta, e como tudo isso se encaixa com o que a ISO 27001, a NIS 2 e o DORA já pedem de você.

O que é a ISO 22301 e o problema que ela resolve

A ISO 22301:2019 é a norma internacional para sistemas de gestão de continuidade de negócios. Não é um manual de recuperação de TI: é um framework para a organização identificar que atividades não pode se dar ao luxo de perder, por quanto tempo, e o que tem pronto para sustentá-las quando algo falha.

A diferença em relação a um plano de recuperação de desastres é de escopo e de propósito. A recuperação olha para os sistemas; a continuidade olha para o negócio: pessoas, instalações, fornecedores, processos e dados. Um data center replicado não vale nada se a equipe que executa o processo crítico não consegue trabalhar e ninguém decidiu quem declara a crise.

Como as demais normas de sistemas de gestão, ela segue a estrutura de alto nível do Anexo SL, com as suas cláusulas de contexto, liderança, planejamento, apoio, operação, avaliação de desempenho e melhoria. Se a sua organização já trabalha com a ISO 27001, o esqueleto vai parecer familiar e boa parte do sistema pode ser reaproveitada.

O BIA: onde todo o resto se decide

A análise de impacto no negócio, ou BIA, é a peça que sustenta o resto da norma. É onde você responde a uma pergunta desconfortável: se esta atividade para, o que acontece e a partir de quando começa a doer.

Um BIA útil para decidir mede o impacto ao longo do tempo, não em um único momento. A mesma queda de um serviço de faturamento pode ser irrelevante por duas horas, incômoda às oito e grave depois de três dias, quando os prazos de pagamento chegam. Esse perfil temporal é o que depois define prioridades e orçamento.

Um BIA bem feito produz três coisas que você vai usar em todo o resto: as atividades priorizadas, o período máximo tolerável de interrupção de cada uma e os recursos mínimos necessários para sustentá-las, incluindo os fornecedores de que você depende sem nunca ter escrito isso.

O erro mais comum que vejo nos projetos é fazer o BIA por departamento em vez de por atividade. Um departamento não é interrompido: um processo é, e ele quase sempre atravessa vários departamentos e um fornecedor externo.

RTO e RPO, explicados com um caso

São os dois números que governam o investimento, e são confundidos o tempo todo. Vale a pena fixá-los com um exemplo.

Imagine uma empresa de processamento de folha de pagamento. O RTO, objetivo de tempo de recuperação, é por quanto tempo o serviço pode ficar fora antes que o dano se torne inaceitável: digamos, oito horas úteis. O RPO, objetivo de ponto de recuperação, é quantos dados você pode se permitir perder, medido em tempo: se o backup roda de madrugada, o RPO é de vinte e quatro horas, e isso significa que uma falha às seis da tarde apaga um dia inteiro de trabalho que terá de ser refeito à mão.

A consequência prática é direta: baixar o RPO custa tecnologia (replicação, backups mais frequentes) e baixar o RTO custa preparação (ambientes de contingência, procedimentos ensaiados, pessoas treinadas). Colocar os dois em zero é uma fantasia cara, e defini-los sem um BIA é chute.

Há um terceiro número que se esquece e que decide se os outros dois são críveis: o período máximo tolerável de interrupção. Se o RTO que você definiu o ultrapassa, o plano não protege nada: apenas documenta quando vai falhar.

Da estratégia a um plano que alguém realmente executa

Com os objetivos definidos, a norma pede que você escolha estratégias de continuidade e as transforme em procedimentos concretos. As opções habituais são sustentar a atividade em outro lugar, degradá-la para um modo manual acordado, transferi-la a um terceiro, ou aceitar o risco de forma explícita e por escrito.

Aceitar o risco é uma resposta legítima, e vale a pena dizer isso, porque o medo de escrevê-lo leva a inventar planos que ninguém jamais vai executar. O que não é legítimo é não ter decidido.

No lado do plano, o que separa um útil de um decorativo é que ele responde a quatro perguntas sem que ninguém precise interpretar nada: quem decide ativá-lo, quem é avisado e por qual canal quando o e-mail corporativo é exatamente o que caiu, o que acontece nas duas primeiras horas, e como se volta ao normal, que é a parte que quase sempre falta.

Quer se certificar como ISO 22301 Lead Implementer?
Treinamento oficial PECB com um consultor em atividade, no seu ritmo ou com acompanhamento individual, em inglês.

Ver o curso →Falar com Ricardo

Um plano não testado não é um plano

É aqui que os sistemas de gestão que funcionam se separam dos que só existem em uma pasta. A norma exige um programa de exercícios e testes, e não como formalidade: um plano que nunca foi executado contém, sem exceção, premissas falsas.

Os exercícios vão do leve ao pesado e você não precisa começar pelo mais caro: revisão de mesa, exercício simulado (tabletop) com os donos reais, simulação de um componente específico e, por fim, um teste com failover real. Cada nível revela coisas diferentes.

O que quase sempre aparece no primeiro exercício de mesa: o número de contato que já não é de ninguém, o backup que até restaura, mas demora três vezes mais do que o previsto, e o fornecedor crítico cujo contrato não traz nenhum compromisso de recuperação. Nenhum dos três se descobre lendo o plano.

O valor do exercício não está em passar nele. Está na lista do que deu errado, com um responsável e uma data atrás de cada linha.

A continuidade não se prova no dia do incidente: prova-se no dia do exercício. Quem só tem o documento descobre as suas premissas falsas no pior momento possível, e com os clientes olhando.

Como se encaixa com ISO 27001, NIS 2 e DORA

Esta é a parte que mais importa para quem já está dentro de um programa de conformidade, porque evita pagar duas vezes pelo mesmo trabalho.

Com a ISO/IEC 27001 a sobreposição é substancial: estrutura de alto nível compartilhada, análise de contexto, informação documentada, auditoria interna e análise crítica pela direção. O que a ISO 27001 trata como um único controle, a continuidade, a ISO 22301 desenvolve como um sistema completo.

A NIS 2 a exige explicitamente: entre as medidas do seu artigo 21 está a continuidade de negócios, incluindo a gestão de backups, a recuperação de desastres e a gestão de crises. Um sistema conforme a ISO 22301 é a forma mais organizada de evidenciar esse bloco a uma autoridade.

E para as entidades financeiras, o DORA vai ainda mais longe: exige uma política de continuidade de negócios de TIC, planos de resposta e recuperação e testes periódicos com resultados documentados. Os conceitos são os mesmos e o trabalho é quase todo reaproveitável.

Em um projeto real, isso significa que o BIA que você faz para a ISO 22301 vai sustentar decisões nos outros três frameworks. Vale a pena fazê-lo bem uma única vez.

Treinamento e certificação

Se você quer avançar para a certificação oficial PECB, há três níveis conforme o que precisa. ISO 22301 Foundation para dominar o framework e o vocabulário. Lead Implementer se você vai construir o sistema de gestão. Lead Auditor se você vai auditá-lo, por conta própria ou para um organismo de certificação.

Os três podem ser feitos em autoestudo, com o material oficial PECB e no seu ritmo, ou com acompanhamento em sessões individuais comigo, em inglês, se você preferir trabalhar o seu próprio caso em vez de um exemplo de livro.