Recuperação de Desastres, Continuidade de Negócios e Resposta a Incidentes
Recuperação de Desastres, Continuidade de Negócios e Resposta a Incidentes da ProcessMind
Data de vigência: 14 de setembro de 2026
Este documento apresenta um resumo geral dos procedimentos de recuperação de desastres («DR»), continuidade de negócios («BCP») e resposta a incidentes de segurança da ProcessMind B.V. para seu serviço em nuvem. Ele complementa as Medidas de Segurança, a Política de Hospedagem SaaS, o Acordo de Nível de Serviço e o Aditivo de Tratamento de Dados.
O documento explica nossa abordagem atual e não estabelece objetivos contratuais separados de tempo de recuperação, objetivos de ponto de recuperação, garantias de durabilidade dos dados, prazos de notificação, níveis de serviço ou padrões de responsabilidade além do que estiver expressamente previsto no contrato, DPA ou SLA aplicável.
1. Objetivos e Escopo
A ProcessMind mantém estes procedimentos para:
- proteger a confidencialidade, a integridade e a disponibilidade dos Dados do Cliente durante um evento disruptivo
- restaurar componentes críticos do serviço de produção após falhas em sistemas sob controle da ProcessMind
- dar continuidade ao gerenciamento de incidentes, à comunicação com clientes e à tomada de decisões operacionais durante interrupções do serviço
- recuperar-se de falhas de infraestrutura, implantação, aplicação ou camada de dados usando procedimentos documentados e definições de infraestrutura controladas por código-fonte
- identificar e avaliar Incidentes de Segurança, conter ameaças, eliminar as causas-raiz, recuperar sistemas afetados, comunicar-se conforme necessário e registrar as lições aprendidas
Estes procedimentos se aplicam ao serviço de produção em nuvem da ProcessMind e a eventos de segurança que envolvam subprocessadores ou serviços em nuvem, na medida em que afetem o Serviço e estejam dentro da capacidade razoável da ProcessMind de investigar e gerenciar. Os ambientes de desenvolvimento e teste são segregados e não são considerados alvos de recuperação para os compromissos de produção voltados aos clientes.
2. Estratégia de Resiliência
2.1 Projeto Regional. Os serviços de produção são hospedados na AWS EU (Frankfurt, Alemanha, eu-central-1). A arquitetura depende de serviços gerenciados da AWS nessa região, que a AWS opera em várias Zonas de Disponibilidade. Atualmente, o cluster Aurora executa uma única instância de gravação; portanto, a recuperação do banco de dados depende de backups automatizados e da recuperação para um ponto no tempo, e não de uma instância em espera na mesma região. Atualmente, a ProcessMind não opera uma segunda região ativa para dados de clientes.
2.2 Serviços Gerenciados e Sem Servidor. A ProcessMind depende do AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon Aurora PostgreSQL, Amazon S3, Amazon SQS, Amazon SNS e Amazon CloudWatch. Isso reduz a dependência de servidores de longa duração gerenciados pelo cliente e permite a recuperação de aplicações e componentes estáticos por meio da reconstrução a partir do código-fonte.
2.3 Separação de Ambientes. Os ambientes de produção e desenvolvimento operam em contas AWS separadas, com bancos de dados e pilhas de infraestrutura distintos. Isso reduz o risco de que atividades de desenvolvimento afetem as operações de recuperação da produção.
2.4 Monitoramento e Detecção. Alarmes do CloudWatch, painéis, alertas de filas de mensagens não processadas, registro centralizado e monitoramento sintético do serviço dão suporte à detecção, triagem e escalonamento de incidentes. Incidentes potenciais também podem ser identificados por meio de solicitações de suporte, relatos de funcionários, notificações de fornecedores ou outros fatores que motivem uma investigação.
3. Prioridades de Recuperação
Durante um incidente grave, as prioridades de recuperação da ProcessMind são, em geral:
- Proteger a integridade dos dados dos clientes e evitar danos adicionais.
- Conter o incidente e estabilizar os sistemas afetados.
- Restaurar os principais meios de acesso à produção e os fluxos de trabalho críticos.
- Validar o comportamento do serviço, a integridade dos dados e o monitoramento antes de declarar a recuperação concluída.
- Comunicar atualizações de status, impactos para os clientes e ações de acompanhamento.
A sequência exata pode variar conforme a natureza do incidente, inclusive se ele afetar a integridade dos dados, o acesso dos clientes, o processamento assíncrono ou a infraestrutura de suporte.
4. Procedimentos de Recuperação de Desastres
4.1 Declaração e Coordenação de Incidentes. Interrupções materiais do serviço e incidentes de segurança são submetidos à triagem por meio dos procedimentos de resposta a incidentes. A ProcessMind designa um responsável pelo incidente, limita a participação na resposta a pessoal autorizado, avalia a gravidade e o escopo, coordena os responsáveis técnicos e acompanha as ações de recuperação até que o incidente seja resolvido ou reclassificado para um nível inferior.
4.2 Contenção. A ProcessMind envida esforços comercialmente razoáveis para interromper ou reduzir o impacto em curso antes de iniciar uma restauração mais ampla. Dependendo do modo de falha, as ações de contenção podem incluir reverter alterações recentes, desativar caminhos afetados, isolar componentes com mau funcionamento, pausar o processamento em segundo plano enquanto são realizadas verificações de integridade, revogar ou alternar credenciais ou bloquear atividades abusivas.
4.3 Erradicação. Após estabilizar o impacto imediato, a ProcessMind trabalha para eliminar a causa-raiz ou a condição que contribuiu para o incidente. Isso pode incluir aplicar correções de código ou configuração, remover artefatos maliciosos, alternar segredos, restaurar uma configuração confiável ou fechar caminhos de acesso expostos.
4.4 Recuperação do Banco de Dados. O Aurora PostgreSQL realiza backups automatizados contínuos com um período de retenção de sete (7) dias e oferece suporte à recuperação para um ponto no tempo. Se uma falha no nível do banco de dados, um evento de corrupção ou uma alteração destrutiva acidental exigir restauração, a ProcessMind poderá restaurar o backup adequado mais recente ou um ponto selecionado no tempo, validar o ambiente restaurado e redirecionar o tráfego da aplicação para o banco de dados recuperado.
4.5 Recuperação de Objetos e Artefatos. Os arquivos enviados pelos clientes e os artefatos operacionais são armazenados no Amazon S3. O versionamento está habilitado no bucket de uploads e nos buckets de recursos para permitir a recuperação em caso de exclusão ou substituição acidental. Os buckets de implantação do site e do frontend são tratados como artefatos reproduzíveis e podem ser reconstruídos a partir do código-fonte, em vez de restaurados como backups.
4.6 Recuperação de Cargas de Trabalho Assíncronas. Os caminhos de processamento assíncrono usam filas de mensagens não processadas para reter eventos com falha para investigação. A recuperação pode incluir tentar novamente o processamento de mensagens com falha, executar novamente a lógica de processamento ou reproduzir o trabalho quando o fluxo de trabalho subjacente permitir o reprocessamento seguro.
4.7 Reconstrução da Aplicação e da Infraestrutura. A infraestrutura é gerenciada por meio de definições de infraestrutura como código controladas por código-fonte. Se a infraestrutura da aplicação ou os recursos estáticos precisarem ser recriados, a ProcessMind poderá reconstruir e implantar novamente os componentes afetados a partir de definições controladas por versão e artefatos de compilação.
4.8 Validação Antes do Retorno ao Serviço. Antes de encerrar um incidente, a ProcessMind valida a integridade do serviço usando o monitoramento disponível, registros, verificações sintéticas e verificações funcionais direcionadas, e restaura as funcionalidades afetadas usando procedimentos validados de implantação, recuperação e infraestrutura. Uma análise adicional poderá ser realizada quando o incidente envolver restauração de dados ou risco à integridade dos dados.
5. Medidas de Continuidade de Negócios
5.1 Continuidade Operacional. A ProcessMind mantém procedimentos operacionais documentados para que o tratamento de incidentes, o recebimento de solicitações de suporte dos clientes, a resposta da equipe de engenharia e a tomada de decisões possam continuar durante eventos disruptivos.
5.2 Comunicações. Em caso de incidentes materiais de produção, a ProcessMind envida esforços comercialmente razoáveis para fornecer atualizações pelos canais de suporte ao cliente e, quando apropriado, pela página pública de status em processmind.com/status.
5.3 Gerenciamento Controlado de Alterações. Um ciclo de vida de desenvolvimento de software com defesa em profundidade, várias camadas independentes de validação automatizada, implantações controladas, monitoramento centralizado e análise pós-incidente é usado para reduzir interrupções evitáveis e melhorar a continuidade ao longo do tempo.
5.4 Segurança durante a recuperação. As ações de recuperação são realizadas de acordo com os mesmos princípios gerais de segurança aplicáveis durante as operações normais, incluindo acesso com privilégios mínimos, registro das atividades operacionais quando disponível e acesso controlado aos sistemas e dados de produção.
6. Resumo de backup e proteção de dados
6.1 Backups do banco de dados. Os backups automatizados do Aurora são criptografados e retidos por sete (7) dias, com recuperação pontual disponível dentro desse período de retenção.
6.2 Proteções do S3. O Amazon S3 oferece alta durabilidade para objetos armazenados. Os buckets de dados de clientes mutáveis dependem da durabilidade e do versionamento na região primária. Atualmente, a ProcessMind não habilita a replicação entre regiões do S3 para esses buckets.
6.3 Registros e diagnósticos. Registros, alarmes e telemetria centralizados dão suporte à investigação de falhas e à validação da recuperação. Esses mecanismos dão suporte às operações de continuidade, mas não são apresentados, por si só, como um produto de backup separado.
7. Identificação e triagem de incidentes
7.1 Avaliação inicial. Os eventos relatados são submetidos à triagem para determinar se atendem à definição de Incidente de Segurança, quais sistemas ou dados podem ter sido afetados, o provável escopo e a gravidade e se é necessário realizar contenção imediata. A preservação de evidências é realizada de maneira adequada à natureza do incidente e aos sistemas envolvidos.
7.2 Plantão e escalonamento. A ProcessMind mantém cobertura de plantão para incidentes de produção, incluindo cobertura 24 horas por dia, 7 dias por semana, para incidentes Críticos (conforme definidos no Acordo de Nível de Serviço), para que os incidentes possam ser reconhecidos e submetidos à triagem a qualquer momento.
7.3 Documentação. A ProcessMind documenta as constatações relevantes da investigação, as ações de resposta e as decisões de recuperação para que a cronologia do incidente e as ações corretivas resultantes possam ser analisadas após o evento.
8. Comunicações e notificações
8.1 Comunicação interna. A ProcessMind coordena os responsáveis pela resposta, os tomadores de decisão e os canais de suporte para que a resposta técnica e a comunicação com os clientes permaneçam alinhadas durante todo o ciclo de vida do incidente.
8.2 Notificação aos clientes. No caso de um Incidente de Segurança que exija notificação nos termos do DPA ou da legislação aplicável, a ProcessMind notificará os clientes afetados sem demora indevida e, quando viável, no prazo de setenta e duas (72) horas após tomar conhecimento do incidente. Em geral, as notificações incluem a natureza e o escopo do incidente, as categorias de dados afetadas, se conhecidas, as medidas tomadas para conter e remediar o incidente e as ações recomendadas aos clientes, quando pertinentes.
8.3 Atualizações contínuas. Quando o incidente permanecer ativo ou fatos relevantes mudarem, a ProcessMind fornecerá atualizações subsequentes à medida que informações adicionais verificadas estiverem disponíveis. Para interrupções mais amplas dos serviços de produção, a ProcessMind também poderá usar os canais de suporte ao cliente e, quando apropriado, a página pública de status em processmind.com/status.
9. Testes, análise e manutenção
A ProcessMind analisa estes procedimentos pelo menos anualmente e após incidentes relevantes ou mudanças arquitetônicas significativas, testa periodicamente elementos pertinentes da abordagem de resposta e recuperação (como restauração de backups, reconstrução de implantações, monitoramento, alertas e comunicações sobre incidentes) e incorpora as lições aprendidas aos seus procedimentos de segurança, confiabilidade e continuidade.
10. Limitações e limites contratuais
Este documento é um resumo de alto nível e não descreve em detalhes operacionais todos os manuais internos, caminhos de escalonamento, métodos de investigação ou etapas de tratamento de evidências. Ele não compromete a ProcessMind a adotar um projeto separado de failover entre regiões, retenção em armazenamento imutável para todos os buckets mutáveis ou garantias independentes de RTO/RPO além do que estiver expressamente estabelecido no contrato ou pedido aplicável.
Em caso de conflito entre este documento e o Contrato do Cliente, o Adendo de Tratamento de Dados, o Acordo de Nível de Serviço ou a legislação obrigatória aplicável, prevalecerão essas fontes.