Como criar o Procedimento de Comunicação de Incidentes do seu cartório

Um incidente de segurança pode ser um ransomware que criptografa os dados do sistema, um acesso não autorizado ao banco de dados, um vazamento de informações pessoais, ou até uma falha de sistema que deixa o cartório sem atendimento por horas. O Procedimento de Comunicação de Incidentes é o documento que define o que fazer quando isso acontece: como identificar, classificar, conter, comunicar e registrar.

Os itens 1.5 e 1.6 da Etapa 1 do Provimento 213 exigem que a serventia tenha um procedimento documentado para comunicação de incidentes críticos à Corregedoria e à ANPD. A Política de Segurança da Informação define as diretrizes gerais de gestão de incidentes; este documento detalha o procedimento operacional.

O que o provimento exige

O provimento estabelece que:

Incidentes classificados como críticos devem ser comunicados à Corregedoria competente nos prazos e condições do Anexo II
Como meta de diligência reforçada, a comunicação deve ocorrer em até 24 horas da ciência do incidente
Incidentes que envolvam dados pessoais devem ser comunicados à ANPD nos termos da LGPD (art. 48)
A serventia deve manter registro de todos os incidentes, independentemente da gravidade

Estrutura do documento

1. Objetivo

Este procedimento estabelece o fluxo de identificação, classificação, contenção, comunicação e registro de incidentes de segurança da informação na serventia [nome do cartório], em conformidade com os itens 1.5 e 1.6 do Provimento 213 do CNJ e com o art. 48 da LGPD.

2. Definições

Antes de detalhar o procedimento, defina os termos que serão usados ao longo do documento. Os colaboradores precisam entender o que constitui um incidente.

Incidente de segurança da informação: qualquer evento que comprometa ou possa comprometer a confidencialidade, integridade, disponibilidade, autenticidade ou rastreabilidade das informações da serventia.

Exemplos práticos para o contexto de cartórios:

Sistema fora do ar por falha técnica ou ataque
Computador infectado por vírus ou ransomware
Acesso não autorizado a dados de atos ou de partes
Vazamento de dados pessoais (envio de informações ao destinatário errado, exposição indevida)
Perda ou furto de equipamento com dados da serventia (notebook, HD externo, pen drive)
E-mail de phishing que resultou em comprometimento de credenciais
Colaborador usando credencial de outro colaborador
Falha de backup detectada (backup não executou, mídia corrompida)
Desligamento abrupto do servidor com possível corrupção de dados

3. Classificação de incidentes

O Anexo II do provimento define critérios de classificação. Use a tabela abaixo como referência para classificar os incidentes da serventia:

Nível	Critério	Exemplos	Prazo de comunicação
Crítico	Indisponibilidade prolongada, comprometimento de dados pessoais em larga escala, ataque cibernético com impacto sistêmico	Ransomware, vazamento massivo de dados, invasão do servidor, indisponibilidade acima do RTO	Corregedoria: até 24h. ANPD: até 72h (se envolver dados pessoais)
Alto	Comprometimento parcial de sistemas, vazamento de dados pessoais em escala limitada, falha de controle de segurança	Malware em estação de trabalho, acesso não autorizado a dados, falha de backup por mais de 24h	Registro interno obrigatório. Avaliar comunicação à Corregedoria
Médio	Tentativa de ataque contida, falha pontual sem perda de dados, vulnerabilidade identificada	Tentativa de phishing bloqueada, falha de hardware sem perda, vulnerabilidade em software	Registro interno obrigatório
Baixo	Eventos menores sem impacto operacional	Alerta de antivírus (ameaça bloqueada), tentativa de login mal-sucedida, oscilação breve de energia	Registro interno

A classificação deve ser feita pelo responsável técnico. Na dúvida entre dois níveis, classifique no nível mais alto. É melhor comunicar um incidente que poderia ter sido classificado como menor do que deixar de comunicar um incidente que deveria ter sido reportado.

4. Fluxo de resposta

O fluxo de resposta segue seis etapas. O documento deve detalhar cada uma com ações concretas, responsáveis e prazos.

Etapa 1: Identificação

Quem identifica: qualquer colaborador da serventia.

O que fazer:

Ao detectar ou suspeitar de um incidente, comunicar imediatamente ao responsável técnico (pessoalmente, por telefone ou mensagem)
Não tentar resolver sozinho, especialmente em casos de malware ou acesso não autorizado
Se possível, preservar a evidência: não desligar o computador afetado (a menos que haja instrução específica), não apagar mensagens suspeitas, anotar o horário e o que foi observado

Canais de comunicação interna:

Canal	Contato	Uso
Responsável técnico	[nome, telefone, e-mail]	Primeiro contato para qualquer incidente
Titular da delegação	[nome, telefone]	Quando o responsável técnico não estiver disponível, ou para incidentes críticos
Substituto do responsável técnico	[nome, telefone]	Quando o responsável técnico estiver ausente

Etapa 2: Classificação

Quem classifica: responsável técnico.

O que fazer:

Avaliar o incidente conforme a tabela de classificação (seção 3)
Determinar o escopo: quantos sistemas, estações ou dados foram afetados
Verificar se há dados pessoais envolvidos
Registrar a classificação inicial (pode ser reclassificado depois, conforme a investigação avançar)
Se o incidente for classificado como crítico, comunicar imediatamente ao titular e iniciar o fluxo de comunicação externa (Etapa 4)

Etapa 3: Contenção

Quem executa: responsável técnico, com apoio do suporte de TI contratado (se houver).

Ações por tipo de incidente:

Tipo de incidente	Ações de contenção
Malware/ransomware	Desconectar a máquina da rede (cabo e Wi-Fi). Não desligar. Não pagar resgate. Isolar outros equipamentos se necessário
Acesso não autorizado	Revogar imediatamente as credenciais comprometidas. Forçar troca de senha. Verificar logs de acesso
Vazamento de dados	Identificar a extensão do vazamento. Interromper o compartilhamento indevido. Preservar evidências
Falha de sistema (SaaS)	Contatar o fornecedor do sistema. Verificar status do serviço. Ativar contingência se indisponibilidade exceder 30 minutos
Falha de servidor (on-premise)	Contatar suporte técnico. Avaliar se o problema é hardware ou software. Não tentar reparos sem orientação técnica
Perda/furto de equipamento	Registrar boletim de ocorrência. Revogar acessos do equipamento. Avaliar quais dados estavam no dispositivo

O objetivo da contenção é impedir que o incidente se agrave. Não é o momento de investigar a causa raiz ou restaurar sistemas.

Etapa 4: Comunicação externa

Esta é a etapa que o provimento regulamenta com mais detalhe. A comunicação externa é obrigatória para incidentes críticos e para incidentes que envolvam dados pessoais.

Comunicação à Corregedoria:

Item	Detalhe
Quando	Incidentes classificados como críticos. Meta: até 24 horas da ciência do incidente
Para quem	Corregedoria competente (estadual ou do DF, conforme a serventia)
Como	Conforme canal definido pela Corregedoria (sistema eletrônico, e-mail institucional, ofício)
O que comunicar	Data/hora do incidente, descrição resumida, sistemas afetados, dados comprometidos (se houver), ações de contenção tomadas, previsão de restabelecimento

Comunicação à ANPD (quando envolver dados pessoais):

Item	Detalhe
Quando	Incidentes que possam acarretar risco ou dano relevante aos titulares de dados pessoais
Para quem	Autoridade Nacional de Proteção de Dados (ANPD)
Prazo	Até 72 horas da ciência do incidente (conforme regulamentação da ANPD)
Como	Formulário eletrônico no site da ANPD (Peticionamento Eletrônico)
O que comunicar	Natureza dos dados afetados, titulares envolvidos, medidas técnicas e de segurança adotadas, riscos relacionados, medidas para reverter ou mitigar os efeitos

Comunicação aos titulares de dados:

Quando o incidente envolver dados pessoais e puder acarretar risco ou dano relevante, os titulares afetados também devem ser comunicados (art. 48, §1º da LGPD). A comunicação deve ser clara, em linguagem acessível, e conter:

Descrição do incidente
Quais dados foram afetados
Quais medidas foram tomadas
Recomendações ao titular (trocar senhas, monitorar contas)
Canal de contato do DPO da serventia

Contatos de comunicação externa:

Destinatário	Canal	Contato	Responsável pela comunicação
Corregedoria [estado]	[sistema/e-mail/ofício]	[contato]	Titular da delegação
ANPD	Peticionamento Eletrônico	gov.br/anpd	DPO / responsável técnico
Polícia (se aplicável)	Boletim de ocorrência	Delegacia mais próxima / delegacia online	Titular da delegação

Mantenha esses contatos atualizados e acessíveis. Num incidente crítico, não é hora de procurar o telefone da Corregedoria.

Etapa 5: Recuperação

Quem executa: responsável técnico, com apoio do suporte de TI e do fornecedor do sistema.

A recuperação segue os procedimentos definidos no PCN/PRD. As ações dependem do tipo de incidente:

Tipo de incidente	Ações de recuperação
Malware/ransomware	Formatar a máquina. Restaurar dados a partir do backup. Verificar integridade do backup antes de restaurar. Atualizar antivírus. Aplicar patches pendentes
Acesso não autorizado	Revisar todas as credenciais. Implementar MFA se não estiver ativo. Analisar logs para identificar o escopo do acesso
Vazamento de dados	Documentar a extensão. Implementar controles para evitar recorrência. Revisar permissões de acesso
Falha de sistema (SaaS)	Aguardar restabelecimento pelo fornecedor. Verificar integridade dos dados após retorno. Solicitar relatório de causa raiz
Falha de servidor (on-premise)	Reparar ou substituir hardware. Restaurar sistema e banco de dados a partir do backup. Testar integridade antes de retomar atendimento

Antes de retomar o atendimento, verificar:

Sistema operando normalmente
Dados íntegros (comparar com último backup conhecido)
Controles de segurança ativos (antivírus, firewall, MFA)
Causa do incidente eliminada (não adianta restaurar se a vulnerabilidade continua)

Etapa 6: Registro e análise pós-incidente

Todo incidente, independentemente da gravidade, deve ser registrado. O registro é a evidência de que a serventia tem um processo de gestão de incidentes funcionando.

Informações que devem ser registradas:

Campo	Descrição
Número do incidente	Identificador sequencial (ex.: INC-2026-001)
Data e hora da detecção	Quando o incidente foi identificado
Data e hora do início estimado	Quando o incidente provavelmente começou
Quem identificou	Nome do colaborador
Classificação	Crítico / Alto / Médio / Baixo
Descrição	O que aconteceu, de forma objetiva
Sistemas afetados	Quais sistemas, estações ou dados foram impactados
Dados pessoais envolvidos	Sim/Não. Se sim, quais categorias e quantidade estimada de titulares
Ações de contenção	O que foi feito para limitar o impacto
Comunicações realizadas	Corregedoria, ANPD, titulares, polícia (com datas e protocolos)
Ações de recuperação	O que foi feito para restaurar a operação
Causa raiz	O que causou o incidente (se identificado)
Tempo de indisponibilidade	Duração total da interrupção, se houver
Lições aprendidas	O que pode ser melhorado para evitar recorrência
Ações corretivas	Medidas implementadas após o incidente
Responsável pelo registro	Nome de quem documentou
Data de encerramento	Quando o incidente foi considerado resolvido

Análise pós-incidente:

Para incidentes classificados como críticos ou altos, conduza uma análise pós-incidente (post-mortem) dentro de 5 dias úteis após o encerramento. O objetivo não é encontrar culpados, é identificar o que falhou e como evitar que aconteça de novo.

A análise deve responder:

O que aconteceu? (linha do tempo dos eventos)
O que causou? (causa raiz)
O procedimento de resposta funcionou? (o que foi seguido, o que não foi, o que faltou)
O que precisa mudar? (ações corretivas)

Documente a análise e atualize o procedimento de incidentes, o PCN/PRD e a Política de Segurança da Informação se necessário.

5. Responsabilidades

Papel	Responsabilidade
Todos os colaboradores	Identificar e comunicar incidentes ou suspeitas ao responsável técnico
Responsável técnico	Classificar, coordenar contenção e recuperação, registrar o incidente
DPO	Avaliar envolvimento de dados pessoais, conduzir comunicação à ANPD e aos titulares
Titular da delegação	Autorizar comunicação à Corregedoria, assinar notificações formais
Suporte de TI (contratado)	Apoiar contenção e recuperação técnica

6. Prazos resumidos

Ação	Prazo
Comunicação interna (colaborador → responsável técnico)	Imediato
Classificação do incidente	Até 2 horas após a comunicação interna
Início da contenção	Imediato após classificação
Comunicação à Corregedoria (incidentes críticos)	Até 24 horas da ciência
Comunicação à ANPD (se envolver dados pessoais)	Até 72 horas da ciência
Comunicação aos titulares (se aplicável)	Em prazo razoável, conforme orientação da ANPD
Registro completo do incidente	Até 48 horas após o encerramento
Análise pós-incidente (críticos/altos)	Até 5 dias úteis após o encerramento

7. Simulações

A serventia deve realizar pelo menos uma simulação anual de resposta a incidentes. O objetivo é testar se o procedimento funciona na prática, se os colaboradores sabem o que fazer e se os contatos estão atualizados.

Cenários sugeridos para simulação:

Phishing: enviar um e-mail simulado de phishing para os colaboradores e verificar quem identifica e comunica corretamente
Ransomware: simular a detecção de ransomware em uma estação e executar o procedimento completo (contenção, classificação, comunicação)
Indisponibilidade de sistema: simular uma falha do sistema principal e verificar se a equipe consegue ativar a contingência e comunicar nos prazos
Vazamento de dados: simular a identificação de um envio indevido de dados pessoais e verificar se o fluxo de comunicação (ANPD, titulares) é executado corretamente

Registre cada simulação com data, cenário, participantes, resultado e melhorias identificadas.

8. Versão impressa

Assim como o Plano de Contingência Energética, este procedimento deve ter uma versão impressa acessível. Num incidente de ransomware ou indisponibilidade de sistema, os colaboradores podem não conseguir acessar o documento digital.

A versão impressa deve incluir, no mínimo:

Contatos de comunicação interna e externa (Corregedoria, ANPD, suporte de TI)
Tabela de classificação de incidentes
Ações imediatas por tipo de incidente (contenção)
Prazos de comunicação

9. Manutenção

O procedimento deve ser revisado:

Anualmente, junto com a simulação
Após qualquer incidente real (incorporando as lições aprendidas)
Quando houver mudança de responsável técnico, DPO ou titular
Quando a Corregedoria ou a ANPD alterar canais ou prazos de comunicação

Erros comuns

Não ter o procedimento pronto antes do incidente. A hora de definir quem comunica, por qual canal e em que prazo não é durante a crise. É agora.

Confundir incidente com problema técnico. Uma lentidão no sistema pode ser só um problema técnico, mas se houver perda de dados ou acesso não autorizado, é um incidente. Na dúvida, registre como incidente e reclassifique depois.

Não registrar incidentes menores. Incidentes de nível baixo e médio parecem irrelevantes, mas o padrão importa. Três tentativas de phishing em um mês indicam que a serventia está sendo alvo. Sem registro, ninguém percebe.

Comunicar tarde demais. A meta de 24 horas para a Corregedoria e 72 horas para a ANPD não começa quando o incidente é resolvido. Começa quando a serventia toma ciência do incidente. Se o responsável técnico fica sabendo na segunda-feira e só comunica na sexta, o prazo já estourou.

Não testar o procedimento. Um procedimento que nunca foi simulado é um procedimento que provavelmente não vai funcionar quando precisar. A primeira simulação costuma revelar contatos desatualizados, etapas confusas e responsabilidades mal definidas.

Documentação complementar

O Procedimento de Comunicação de Incidentes se conecta com outros documentos da serventia:

A Política de Segurança da Informação define as diretrizes gerais de gestão de incidentes (seção 8 da PSI)
O PCN e PRD detalham os procedimentos de recuperação que são acionados após a contenção do incidente
O ROPA/RAT identifica os dados pessoais tratados pela serventia, necessário para avaliar o impacto de incidentes que envolvam dados pessoais
O Documento de Arquitetura Tecnológica mapeia os sistemas e fluxos de dados que podem ser afetados por um incidente

Após a aprovação do procedimento, ele precisa ser divulgado a todos os colaboradores com registro de ciência. O SIG Virtual permite publicar o procedimento na plataforma, atribuir aos colaboradores e registrar quem leu e confirmou. Além disso, o módulo de gestão de incidentes permite registrar e acompanhar cada ocorrência de forma centralizada, com histórico, classificação e evidências.

Referências

O SIG Virtual ajuda serventias a organizar procedimentos, registrar incidentes e manter a rastreabilidade exigida pelo Provimento 213. Se o seu cartório precisa estruturar a gestão de incidentes, faça o teste gratuito e veja como funciona. Confira nossos planos e preços ou entre em contato.