Como elaborar o PCN e PRD do seu cartório

O PCN (Plano de Continuidade de Negócios) e o PRD (Plano de Recuperação de Desastres) são os documentos que definem como o cartório vai continuar operando quando algo der errado e como vai voltar ao normal depois. Ransomware, queda de sistema, falha de servidor, desastre natural, perda de pessoal-chave, falha de fornecedor: o plano precisa cobrir tudo isso.

O item 2.5 da Etapa 2 do Provimento 213 exige a formalização desses planos com quatro elementos obrigatórios. Sem todos eles, a declaração de conclusão da etapa não pode ser emitida.

PCN e PRD: um documento ou dois?

O provimento permite que sejam documentos separados ou integrados, desde que contenham todos os elementos obrigatórios. Na prática, para a maioria das serventias, faz mais sentido um documento único dividido em duas partes:

PCN: foca em manter as operações críticas funcionando durante o incidente. Como continuar atendendo, como manter os atos registrais acessíveis, como operar em modo degradado;
PRD: foca em restaurar o ambiente tecnológico ao estado normal. Como recuperar o sistema, restaurar backups, reconstruir a infraestrutura.

O PCN responde “como sobrevivemos enquanto o problema não é resolvido” e o PRD responde “como resolvemos o problema e voltamos ao normal”.

Os 4 elementos obrigatórios

O provimento exige que o documento contenha, cumulativamente:

Identificação e avaliação estruturada de riscos
Definição objetiva das medidas de mitigação
RTO e RPO compatíveis com a classe da serventia
Medidas de curto prazo (até 30 dias) e médio prazo (até 90 dias)

Vamos detalhar cada um.

1. Identificação e avaliação de riscos

O primeiro passo é listar os riscos que podem interromper as operações da serventia e avaliar cada um em termos de probabilidade e impacto.

Riscos comuns a todas as serventias

Risco	Descrição	Exemplo de cenário
Queda de energia	Interrupção no fornecimento elétrico	Queda prolongada sem gerador, nobreak esgotado
Falha de conectividade	Perda dos links de internet	Dois provedores fora simultaneamente
Ataque cibernético	Ransomware, invasão, phishing	Ransomware criptografa dados e exige resgate
Falha de sistema	Sistema de gestão fora do ar	Atualização com erro, bug crítico, indisponibilidade do provedor SaaS
Desastre natural	Incêndio, inundação, tempestade	Alagamento do escritório, incêndio na sala de equipamentos
Perda de pessoal-chave	Afastamento do titular, do DPO ou do técnico responsável	Acidente, doença, desligamento sem transição
Falha de fornecedor	Fornecedor de tecnologia encerra contrato ou sai do mercado	Provedor do sistema cancela o serviço
Pandemia/crise sanitária	Impossibilidade de acesso físico ao cartório	Lockdown, quarentena obrigatória

Riscos adicionais para serventias com servidor local

Risco	Descrição	Exemplo de cenário
Falha de hardware do servidor	Disco, memória, placa-mãe, fonte	Disco rígido queima, servidor não liga
Corrupção de banco de dados	Dados corrompidos por falha elétrica ou software	Desligamento abrupto corrompe tabelas do banco
Furto de equipamentos	Servidor ou backup local roubados	Arrombamento do escritório no final de semana
Perda do técnico de TI	Único técnico que conhece o servidor sai	Técnico terceirizado encerra contrato sem documentação
Falha de climatização	Ar-condicionado da sala de servidores para	Servidor superaquece e desliga

Como avaliar

Para cada risco, atribua uma classificação de probabilidade e impacto. Uma matriz simples funciona:

Probabilidade:

Alta: já aconteceu ou é esperado que aconteça (ex.: queda de energia em regiões com fornecimento instável)
Média: possível, mas não frequente
Baixa: improvável, mas não impossível (ex.: incêndio)

Impacto:

Crítico: interrupção total das operações, perda de dados, impossibilidade de prestar o serviço
Alto: interrupção parcial, degradação significativa do serviço
Médio: inconveniente operacional, sem perda de dados
Baixo: impacto mínimo, resolvido rapidamente

Risco	Probabilidade	Impacto	Prioridade
Queda de energia	Alta	Alto	Crítica
Ransomware	Média	Crítico	Crítica
Falha de conectividade	Média	Alto	Alta
Falha de sistema (SaaS)	Baixa	Crítico	Alta
Falha de hardware (on-premise)	Média	Crítico	Crítica
Desastre natural	Baixa	Crítico	Média
Perda de pessoal-chave	Média	Alto	Alta
Falha de fornecedor	Baixa	Crítico	Alta

Adapte a tabela à realidade da sua serventia. Um cartório em região com enchentes frequentes vai classificar “desastre natural” com probabilidade maior do que um cartório no centro de São Paulo.

2. Medidas de mitigação

Para cada risco identificado, definir o que será feito para reduzir a probabilidade ou o impacto. A mitigação acontece antes do incidente.

Risco	Medida de mitigação	Status
Queda de energia	Nobreak com 30 min de autonomia, plano de contingência energética, notebooks de contingência	Implementado
Ransomware	Backup off-site automatizado, antivírus em todas as estações e servidores, treinamento contra phishing, segmentação de rede	Em andamento
Falha de conectividade	Dois links de provedores diferentes, roteador 4G/5G de contingência	Implementado
Falha de sistema (SaaS)	SLA contratual com o provedor, verificar redundância do provedor, procedimento para operação manual temporária	Verificar SLA
Falha de hardware (on-premise)	Contrato de suporte com SLA, peças de reposição críticas, backup off-site	Em andamento
Desastre natural	AVCB, extintor, seguro patrimonial, backup off-site em localidade diferente	Implementado
Perda de pessoal-chave	Documentação de procedimentos, pelo menos duas pessoas capacitadas para cada função crítica, senhas em cofre	Parcial
Falha de fornecedor	Cláusulas contratuais de portabilidade e reversibilidade (item 1.8 do provimento), backup dos dados em formato aberto	Verificar contratos

A coluna “Status” ajuda a acompanhar o que já está feito e o que ainda precisa ser implementado. Esse acompanhamento pode ser feito no SIG Virtual, que permite registrar planos de ação com responsáveis, prazos e status.

3. RTO e RPO

O provimento define parâmetros de RTO e RPO por classe da serventia:

Classe	Faturamento semestral	RPO (perda máxima de dados)	RTO (tempo para restaurar)
Classe 3	Acima de R$ 500 mil	4 horas	8 horas
Classe 2	R$ 100 mil a R$ 500 mil	12 horas	24 horas
Classe 1	Até R$ 100 mil	24 horas	24 horas

RPO (Recovery Point Objective): quanto tempo de dados você aceita perder. Se o RPO é 4 horas, o backup precisa rodar no mínimo a cada 4 horas. Se der um desastre, você perde no máximo 4 horas de trabalho.

RTO (Recovery Time Objective): quanto tempo o sistema pode ficar fora do ar. Se o RTO é 8 horas, a serventia precisa ser capaz de restaurar a operação em até 8 horas após o incidente.

Como garantir o RPO

Sistema SaaS: verificar com o provedor qual a frequência de backup e se atende ao RPO da classe. A maioria dos provedores SaaS faz backups com frequência superior à exigida. Solicitar documentação;
Servidor local: configurar backup automatizado com frequência compatível com o RPO. Para Classe 3 (RPO de 4 horas), isso significa backup incremental a cada 4 horas no máximo. O backup precisa estar off-site, não apenas no mesmo local do servidor.

Como garantir o RTO

Sistema SaaS: o RTO depende principalmente do provedor. Verificar o SLA contratual e o histórico de disponibilidade. A contingência da serventia se resume a ter conectividade (link secundário, 4G/5G) e estações funcionando;
Servidor local: o RTO depende da serventia. Considerar: tempo para diagnosticar o problema, tempo para substituir hardware (se necessário), tempo para restaurar o backup, tempo para verificar integridade e retomar o atendimento. Para cumprir um RTO de 8 horas com servidor local, a serventia precisa ter peças de reposição ou contrato de suporte com SLA compatível.

Documentando no plano

Para cada processo crítico da serventia, registre:

Processo	RPO alvo	RPO atual	RTO alvo	RTO atual	Lacuna
Registro de atos	4h	4h (backup a cada 4h)	8h	~6h (estimado)	OK
Emissão de certidões	4h	4h	8h	~6h	OK
Atendimento ao público	—	—	8h	~2h (contingência com notebook)	OK

Se houver lacuna entre o alvo e o atual, registre o plano de ação para fechar essa diferença.

4. Medidas de curto e médio prazo

O provimento exige que o plano preveja ações em dois horizontes temporais:

Curto prazo (até 30 dias após o incidente)

São as ações imediatas de resposta. O que acontece nas primeiras horas e dias:

Nas primeiras horas:

Identificar e classificar o incidente;
Ativar o plano de contingência aplicável (energética, conectividade, etc.);
Comunicar o titular da delegação;
Se o incidente for crítico, comunicar a Corregedoria (meta de 24 horas);
Se envolver dados pessoais, avaliar necessidade de comunicação à ANPD;
Conter o incidente (isolar sistemas afetados, bloquear acessos comprometidos).

Nos primeiros dias:

Ativar operação em modo degradado se necessário (atendimento manual, notebooks, 4G/5G);
Iniciar recuperação do ambiente (restauração de backup, substituição de hardware);
Comunicar a equipe sobre o status e os procedimentos temporários;
Registrar todas as ações tomadas, decisões e comunicações;
Se o atendimento estiver suspenso, comunicar o público (aviso na porta, redes sociais, telefone).

Até 30 dias:

Concluir a restauração do ambiente tecnológico;
Verificar integridade dos dados restaurados;
Retomar a operação normal;
Documentar o incidente completo: cronologia, causa raiz, impacto, ações tomadas, dados afetados.

Médio prazo (até 90 dias após o incidente)

São as ações de consolidação e melhoria:

Analisar a causa raiz do incidente e implementar correções definitivas;
Revisar o PCN e PRD com base nas lições aprendidas;
Atualizar a análise de riscos se o incidente revelou riscos não mapeados;
Reforçar as medidas de mitigação que falharam ou se mostraram insuficientes;
Conduzir treinamento com a equipe sobre os procedimentos revisados;
Produzir relatório final do incidente para arquivo e eventual fiscalização.

Estrutura recomendada do documento

Reunindo tudo, o documento pode seguir esta estrutura:

Objetivo e escopo
Responsabilidades (quem ativa o plano, quem coordena a recuperação, quem comunica a Corregedoria)
Processos críticos da serventia (registro de atos, emissão de certidões, atendimento ao público, integração com centrais eletrônicas)
Análise de riscos (tabela de riscos com probabilidade e impacto)
Medidas de mitigação (tabela com medidas e status)
Parâmetros de RTO e RPO (por processo crítico, com alvo e situação atual)
Procedimentos de resposta por cenário (ransomware, falha de energia, falha de sistema, desastre natural, etc.)
Medidas de curto prazo (até 30 dias)
Medidas de médio prazo (até 90 dias)
Testes e simulações (periodicidade, o que testar, como registrar)
Contatos de emergência (Corregedoria, ANPD, fornecedores, suporte técnico)
Histórico de revisões

Procedimentos de resposta por cenário

Para cada risco prioritário, vale detalhar o procedimento específico. Aqui estão os mais relevantes para cartórios:

Cenário: Ransomware

Desconectar imediatamente o equipamento afetado da rede (cabo e Wi-Fi);
Não pagar o resgate;
Verificar se outros equipamentos foram comprometidos;
Desligar equipamentos não afetados como medida preventiva, se necessário;
Comunicar o responsável técnico e o titular;
Comunicar a Corregedoria (incidente crítico);
Avaliar se houve comprometimento de dados pessoais (comunicar ANPD se positivo);
Acionar o suporte técnico e/ou empresa de resposta a incidentes;
Restaurar os sistemas a partir do backup off-site mais recente;
Verificar integridade dos dados restaurados antes de retomar o atendimento;
Investigar o vetor de ataque (como o ransomware entrou) e corrigir a vulnerabilidade;
Documentar o incidente completo.

Cenário: Falha de sistema (SaaS)

Verificar se o problema é local (conectividade) ou do provedor (sistema indisponível);
Se for local, ativar link secundário ou 4G/5G;
Se for do provedor, contatar o suporte e registrar o chamado;
Ativar operação em modo degradado: atendimento manual, registro dos atos em formulário provisório;
Comunicar o público sobre a situação;
Se a indisponibilidade ultrapassar o RTO, comunicar a Corregedoria;
Quando o sistema voltar, lançar os atos registrados manualmente;
Documentar o incidente e o tempo de indisponibilidade.

Cenário: Falha de hardware do servidor (on-premise)

Diagnosticar o problema (disco, memória, fonte, placa-mãe);
Acionar o suporte técnico com SLA compatível com o RTO;
Se houver peça de reposição disponível, iniciar a substituição;
Se não houver, avaliar se é possível operar temporariamente em outro equipamento;
Restaurar o backup mais recente no novo hardware ou no hardware reparado;
Verificar integridade do banco de dados;
Testar o sistema antes de retomar o atendimento;
Documentar o incidente, incluindo tempo de indisponibilidade e dados perdidos (se houver).

Testes e simulações

O provimento exigirá testes periódicos nas etapas seguintes, mas a recomendação é começar desde já.

O que testar:

Restauração de backup completo: verificar se o backup pode ser restaurado e se os dados estão íntegros. Medir o tempo de restauração e comparar com o RTO;
Simulação de operação em modo degradado: operar com notebooks e 4G/5G por um período e verificar se é viável;
Simulação de comunicação de incidente: testar o fluxo de comunicação (quem avisa quem, em qual ordem);
Teste de failover de conectividade: desligar o link principal e verificar a comutação.

Registrar cada teste com:

Data, cenário testado, participantes;
Resultado, tempo medido, problemas encontrados;
Ações corretivas necessárias;
Assinatura do responsável.

Versão impressa

Assim como o plano de contingência energética, o PCN e PRD devem ter uma versão impressa acessível. Em um cenário de ransomware, por exemplo, os computadores podem estar inacessíveis. A versão impressa deve incluir pelo menos os procedimentos de resposta, os contatos de emergência e os parâmetros de RTO/RPO.

Erros comuns

Plano genérico copiado da internet: a análise de riscos precisa refletir a realidade da serventia. Um cartório de registro de imóveis em cidade pequena tem riscos diferentes de um tabelionato de notas em capital;
RTO e RPO sem lastro: definir RTO de 8 horas sem ter backup off-site, sem contrato de suporte e sem peça de reposição não funciona. Os parâmetros precisam ser alcançáveis com os recursos que a serventia tem;
Ignorar a operação manual: quando o sistema cai, os atos não param de acontecer. O plano precisa prever como registrar atos manualmente e como lançar no sistema depois;
Não testar a restauração de backup: ter backup não significa que ele funciona. Testes de restauração são obrigatórios;
Deixar o plano na gaveta: o plano precisa ser conhecido pela equipe. Se o titular sofre um acidente e ninguém sabe o que fazer, o plano falhou.

Referências

O SIG Virtual ajuda serventias a estruturar planos de continuidade, registrar análises de riscos e acompanhar planos de ação com responsáveis e prazos. Se o seu cartório precisa elaborar o PCN e PRD para cumprir o Provimento 213, faça o teste gratuito e veja como organizar esse processo. Confira nossos planos e preços ou entre em contato.