Um plano que testou. Não um plano que escreveu.
Donos de processos que nunca entram têm na mesma de responder ao questionário de impacto. Delimite a BIA como campanha, escreva os planos por trás dela e teste-os em calendário, com constatações em cada execução.
O que isto substitui
- Metade dos donos de processos deixa de responder após o segundo e-mail de lembrete.
- Dois anos desde a última aprovação; ninguém o abriu desde então.
- O último teste foi um exercício de mesa sem constatações escritas.
O que muda
- Uma campanha de BIA acompanha a distribuição, os lembretes e a tendência de respostas à medida que chegam.
- Cinco domínios de recuperação: DR na cloud, ciber-recuperação, integridade de dados, recuperação de rede, failback.
- Cada execução de teste guarda constatações e data. O plano torna-se um registo de exercícios.
O que faz aqui
- 1Delimite uma BIA como campanha.
Escolha os processos, nomeie os donos, envie e persiga quem não responde com lembretes em vez de um quarto e-mail.
BIA campaigns - 2Recolha respostas de donos sem conta.
Cada dono de processo abre uma ligação com token e responde a um questionário: sem conta, sem palavra-passe, nada para a TI.
BIA questionnaire - 3Escreva os planos de continuidade e recuperação.
DR na cloud, ciber-recuperação, integridade de dados, recuperação de rede e failback têm cada um a sua secção no registo do plano.
Recovery plans - 4Integre a matriz de escalonamento no plano.
Critérios de ativação, de desativação e regras de resposta por gravidade ficam no registo do plano, não num documento paralelo desatualizado.
Continuity plans - 5Execute um teste e registe constatações nele.
Agende-o, inicie-o, conclua-o e duplique a execução para o trimestre seguinte. Cada constatação fica ligada ao teste.
Plan tests - 6Ative um plano num evento real.
Cada declaração cria um registo de ativação com eventos próprios, junto do grafo de dependências e da pontuação de prontidão.
Command Center
Onde a função termina
Ativos e incidentes abrem só para leitura. Planos, testes e equipas de recuperação são seus; o registo de riscos que vai procurar está na secretária de outra pessoa.
Trabalha com
RISKGestor de riscoRisco como estratégia, não como visto.Registos em folhas de cálculo perdem as ligações. Defina a metodologia de pontuação uma vez e deixe cada entrada conter os controlos, processos, incidentes, KRI e vulnerabilidades que realmente toca, com planos de tratamento e aceitações formais registados.
ASSETSGestor de TICorrigido é uma afirmação. Reforçado é uma análise.Um inventário está certo no dia em que foi exportado. Aqui o registo mantém-se vivo, as exceções são decisões escritas e cada sistema é analisado face à sua base com o add-on de hardening.
SOCGestor de SOCO turno acaba. O contexto não.A continuidade é o problema mais difícil de um SOC; morre às sete da manhã. Escala, escalonamento, carga de trabalho e uma passagem assinada mantêm-na viva. Casos e registos de incidentes são seus para fechar — ou apagar.
Pronto para ir
além do GRC tradicional?
14 dias de teste gratuito. Sem cartão. Cloud ou on-premises.