Backups em plataformas SaaS

A adoção de uma plataforma SaaS simplifica infraestrutura, atualizações e acesso, mas pode criar uma suposição perigosa: se o serviço está na cloud, então os dados estão automaticamente protegidos. Disponibilidade, redundância e backup são controlos relacionados, mas não equivalentes.

Um fornecedor pode manter a aplicação disponível perante a avaria de um componente e, ainda assim, não oferecer ao cliente o restauro granular de um documento eliminado. Pode replicar dados entre locais e propagar rapidamente uma corrupção ou eliminação. Pode conservar cópias técnicas para recuperar a plataforma inteira, mas não disponibilizar ao cliente um ponto de recuperação individual.

Por isso, a pergunta “fazem backups?” é demasiado vaga. Uma resposta útil tem de identificar o que é copiado, que incidentes estão cobertos, quanto se pode perder, em quanto tempo se recupera, quem decide e que prova existe.

 

Backup não é o mesmo que sincronização, histórico ou alta disponibilidade

Backup: Cópia separada que permite recuperar dados de um ponto anterior após perda, corrupção ou incidente.

Sincronização: Mantém informação coerente entre locais ou sistemas; pode propagar uma eliminação ou erro.

Histórico de versões: Permite recuperar versões anteriores dentro da aplicação, segundo regras e prazos próprios.

Replicação: Copia alterações para outro ambiente para disponibilidade; nem sempre preserva estados antigos.

Exportação: Entrega dados ao cliente num formato definido; pode apoiar portabilidade, mas não substitui recuperação operacional.

Alta disponibilidade: Reduz interrupções do serviço perante falhas; não resolve necessariamente perda lógica de dados.

 

REGRA PRÁTICA Se o mecanismo não permite regressar a um estado anterior, isolado do incidente, e repor dados utilizáveis, não deve ser tratado como backup apenas porque existem várias cópias.

 

Antes das 12 perguntas: transforme respostas em compromissos

Respostas comerciais como “backup diário”, “redundância geográfica” ou “cumprimos as melhores práticas” não chegam para gerir risco. Procure quatro qualidades: linguagem contratual, métricas mensuráveis, responsabilidades atribuídas e evidência verificável.

Contratual: a resposta deve constar do contrato, SLA, anexo de segurança ou documentação vinculativa aplicável.

Mensurável: frequência, retenção, RPO, RTO, cobertura e prazos não devem depender de interpretações.

Operacional: o processo deve indicar pedido, aprovação, escalada, comunicação, custo e critérios de conclusão.

Demonstrável: relatórios, testes, registos, certificações ou evidência equivalente devem sustentar a afirmação.

 

12 perguntas sobre backups em plataformas SaaS

1. Que dados, metadados e configurações estão incluídos?

Confirme se a cópia abrange documentos, versões, metadados, comentários, decisões de validação, anexos, utilizadores, permissões, logs de auditoria, regras, fluxos e configurações necessárias para reconstruir o processo. Recuperar apenas os ficheiros pode deixar a informação sem contexto, titularidade ou valor probatório.

Peça uma lista de inclusões e exclusões. Integrações, ficheiros temporários, dados de aplicações ligadas e chaves podem ter políticas diferentes.

 

2. Que cenários de perda estão realmente cobertos?

Teste a resposta contra situações concretas: eliminação acidental por um utilizador, alteração indevida, corrupção silenciosa, compromisso de uma conta administrativa, ransomware, falha de região, indisponibilidade prolongada do fornecedor e erro numa atualização. O mesmo desenho de backup pode não responder a todos estes cenários.

 

3. As cópias estão separadas do ambiente de produção?

Pergunte se existe separação de credenciais, contas, tenancies, regiões ou ambientes e se uma conta comprometida na produção pode eliminar ou cifrar as cópias. A CISA recomenda backups offline ou cloud-to-cloud, cifrados, testados e protegidos contra alteração ou eliminação, além da revisão do modelo de responsabilidade partilhada na cloud.

“Está noutro datacenter” não responde à questão se os mesmos privilégios, chaves ou comandos alcançam ambos os ambientes.

 

4. Qual é o RPO para cada categoria de informação?

O Recovery Point Objective indica a perda máxima de dados tolerada, expressa em tempo. Se o RPO for quatro horas, uma recuperação pode fazer a organização regressar até quatro horas. Compare esse intervalo com o ritmo real de submissões, validações, acessos e alterações documentais.

Dados com impactos diferentes podem justificar objetivos diferentes. O NIST recomenda definir RPO por ativo e alinhar frequência e tecnologia de cópia com esse objetivo.

 

5. Qual é o RTO e quando começa a contagem?

O Recovery Time Objective representa o tempo esperado para repor o serviço ou os dados. Esclareça se a contagem começa no incidente, na deteção, na abertura do pedido ou na confirmação do fornecedor. Confirme ainda se o prazo cobre apenas a entrega de ficheiros ou a reposição funcional da aplicação, incluindo configurações, permissões e dependências.

Um RTO só é credível quando foi medido num teste comparável e inclui componentes como dados, aplicação, configuração e chaves.

 

6. Que granularidade de restauro está disponível?

Verifique se é possível recuperar um documento, uma versão, um registo, uma pasta lógica, um prestador, uma unidade, uma base de dados ou todo o ambiente. Quanto mais amplo for o restauro, maior pode ser o impacto sobre alterações legítimas realizadas depois do ponto escolhido.

Pergunte também como são reconciliados dados recuperados com o estado atual e como se evita reintroduzir informação corrompida ou código comprometido.

 

7. Durante quanto tempo são mantidos os pontos de recuperação?

A retenção deve ser suficientemente longa para detetar incidentes tardios, mas não pode ser confundida com conservação indefinida. Peça a sequência real de pontos disponíveis: diários, semanais, mensais ou outro modelo, e confirme o que acontece quando o cliente elimina dados por obrigação ou política.

Distinguir retenção do backup, retenção documental e arquivo evita que uma cópia técnica seja usada como substituto de uma política de conservação aprovada.

 

8. Como são protegidos acessos, chaves e localizações?

Confirme cifragem em trânsito e em repouso, gestão e recuperação de chaves, autenticação forte, privilégio mínimo, separação de funções, registo de acessos e proteção contra eliminação. Pergunte onde são tratados e armazenados os dados, que subcontratantes intervêm e como são controladas transferências internacionais.

Uma cópia cifrada é inútil se a organização não conseguir aceder à chave durante a recuperação; é insegura se a chave puder ser comprometida pelo mesmo caminho que a produção.

 

9. Quando foi realizado o último teste e que evidência existe?

Peça data, âmbito, cenário, volume, resultado, RPO e RTO observados, falhas encontradas e ações corretivas. Um teste a um ficheiro pequeno não prova que uma base de dados, histórico ou ambiente completo possa ser recuperado dentro do prazo do negócio.

O RGPD inclui a capacidade de restabelecer disponibilidade e acesso de forma atempada e um processo regular de teste e avaliação das medidas de segurança. A aplicação concreta deve ser validada pelo responsável competente.

 

10. Quem pode pedir, aprovar e executar um restauro?

Defina contactos, autenticação do pedido, autoridade para decidir, prioridades, comunicação, escalada, janelas de execução e custos. Um processo tecnicamente possível pode falhar porque ninguém sabe quem autoriza a recuperação ou porque o contacto está indisponível fora do horário habitual.

Inclua a responsabilidade do cliente por classificar dados, definir objetivos, manter contactos e validar o resultado; e a do fornecedor por executar, comunicar e preservar evidência, de acordo com o serviço contratado.

 

11. Como são exportados os dados e preparada a saída?

Backup e portabilidade não são iguais, mas uma estratégia de saída reduz dependência. Confirme categorias exportáveis, formatos estruturados, metadados, anexos, logs, documentação técnica, frequência, duração, custo e capacidade de importação noutro ambiente.

O Regulamento dos Dados da União Europeia contém regras sobre mudança de serviços de tratamento de dados, informação de formatos, continuidade e períodos de recuperação. A aplicabilidade e as cláusulas do contrato devem ser revistas por profissionais jurídicos, considerando o tipo de serviço e eventuais exceções.

 

12. O que acontece às cópias no fim do contrato?

O contrato deve explicar o período durante o qual os dados podem ser recuperados, o momento da eliminação, o tratamento de cópias residuais, a emissão de confirmação, os casos de conservação obrigatória e o impacto de litígios ou legal hold. O cliente deve concluir e validar a exportação antes de perder o acesso.

No tratamento de dados pessoais, as instruções, devolução ou eliminação no termo do serviço e as medidas de segurança devem estar alinhadas com os papéis e obrigações aplicáveis ao responsável e ao subcontratante.

 

Grelha rápida de avaliação do fornecedor

Cobertura

Evidência esperada: Inventário de dados, metadados, logs e configurações incluídos.

Sinal de alerta: “Fazemos backup de tudo” sem lista de exclusões.

Recuperação

Evidência esperada: RPO/RTO por serviço, granularidade e procedimento.

Sinal de alerta: Prazos apenas indicativos ou contados após aceitação interna.

Resiliência

Evidência esperada: Separação de ambientes, imutabilidade e controlo de eliminação.

Sinal de alerta: Mesmas credenciais administrativas em produção e backup.

Testes

Evidência esperada: Relatório recente, cenário comparável e ações corretivas.

Sinal de alerta: Teste limitado a um ficheiro sem medição de tempo.

Segurança

Evidência esperada: Cifragem, chaves, acessos, registos, localizações e subcontratantes.

Sinal de alerta: Respostas genéricas sem responsáveis ou evidência.

Operação

Evidência esperada: Contactos, aprovação, escalada, comunicação e custos.

Sinal de alerta: Processo dependente de uma pessoa ou canal informal.

Saída

Evidência esperada: Formatos, âmbito, período de recuperação, apoio e eliminação.

Sinal de alerta: Exportação sem metadados ou sem teste de reutilização.

 

Defina objetivos a partir do impacto do negócio

RPO e RTO não devem ser escolhidos porque o fornecedor já os oferece. Devem partir do impacto da indisponibilidade e da perda de alterações. Uma análise simples por processo documental ajuda a evitar o mesmo nível de serviço para tudo.

Autorizações de acesso

Impacto principal: Bloqueios ou entradas indevidas.

Implicação para backup: Baixa tolerância; recuperação prioritária.

Validações e rejeições

Impacto principal: Perda de decisões e retrabalho.

Implicação para backup: Preservar histórico, comentários e responsáveis.

Documentos legais/contratuais

Impacto principal: Falta de evidência e risco de auditoria.

Implicação para backup: Retenção e recuperação alinhadas com requisitos validados.

Configuração e permissões

Impacto principal: Processo reposto com regras erradas.

Implicação para backup: Incluir no âmbito ou manter reconstrução documentada.

Conteúdo informativo

Impacto principal: Impacto operacional limitado.

Implicação para backup: Objetivos proporcionais ao valor e ao custo.

 

Responsabilidade partilhada: quatro decisões que não deve delegar

Classificar a criticidade da informação e identificar dependências do processo.

Aprovar RPO, RTO, retenção e prioridades de recuperação com os responsáveis de negócio.

Manter contactos, procedimentos internos e autoridade para pedir e validar um restauro.

Testar a continuidade completa, incluindo pessoas, integrações, acessos e comunicação, e não apenas a cópia técnica.

O fornecedor controla a tecnologia e executa o serviço contratado; a organização continua a decidir o que é crítico, que perda tolera e quando o resultado é aceitável. Esta fronteira deve constar de uma matriz de responsabilidades simples e atualizada.

 

Plano de revisão em 30 dias

Semana 1

Inventariar plataformas SaaS e identificar proprietários, dados críticos, integrações e contratos.

Semana 2

Enviar as 12 perguntas, reunir SLA, anexos de segurança, relatórios de testes e documentação de saída.

Semana 3

Comparar necessidades com RPO/RTO, cobertura e retenção; registar lacunas, responsáveis e risco aceite.

Semana 4

Realizar ou observar um teste representativo; atualizar procedimentos, contactos, cláusulas e plano de melhoria.

 

Perguntas frequentes

O fornecedor SaaS é sempre responsável pelo backup?

Não se deve presumir. O contrato e o modelo de responsabilidade partilhada determinam o serviço prestado, enquanto a organização mantém responsabilidades sobre classificação, objetivos, acessos, instruções e continuidade. Confirme por escrito.

A exportação periódica substitui um backup?

Não necessariamente. Pode apoiar soberania e saída, mas pode não preservar versões, relações, permissões, logs ou capacidade de reposição rápida. Deve ser testada como parte de uma estratégia mais ampla.

Qual é um bom RPO ou RTO?

Não existe um valor universal. O objetivo adequado depende do impacto de perder alterações e do tempo máximo tolerável de interrupção para cada processo.

Um backup imutável resolve o risco de ransomware?

Reduz a possibilidade de alteração ou eliminação da cópia, mas não garante que a cópia esteja limpa, completa ou recuperável, nem substitui controlo de acessos, deteção, resposta e testes.

É necessário testar se o fornecedor já apresenta certificações?

Sim. Certificações podem reforçar confiança no sistema de gestão e nos controlos avaliados, mas não demonstram, por si só, que os seus dados e dependências foram recuperados no prazo específico do negócio.

Que áreas devem participar na avaliação?

TI e segurança, proprietário do processo, compras, jurídico, proteção de dados, continuidade e gestão documental. O equilíbrio evita uma decisão apenas técnica ou apenas contratual.

Da avaliação à operação documental

A qualidade do backup depende também da forma como a plataforma é administrada: proprietários identificados, acessos atualizados, configurações documentadas, alterações controladas e procedimentos conhecidos. Uma plataforma tecnicamente robusta pode continuar vulnerável a processos informais ou responsabilidades ambíguas.

O GEDOC Service atua na digitalização, parametrização, administração técnica e apoio à utilização de plataformas de gestão documental, com base nos processos definidos pelo cliente. Esta operação estruturada pode ajudar a manter informação de configuração, responsabilidades e procedimentos controlados, sem substituir a definição dos requisitos legais, de segurança ou de continuidade pela organização e pelos fornecedores competentes.

 

PRÓXIMO PASSO Escolha uma plataforma documental crítica e peça respostas documentadas às 12 perguntas. Se RPO, RTO, granularidade, teste ou saída não puderem ser demonstrados, registe a lacuna como risco e atribua uma ação com prazo e proprietário.

Conheça o GEDOC Service e consulte os conteúdos complementares sobre Validação de Recuperação e backup 3-2-1-1-0.

 

Sugestões de artigos 

Categoria Backups — todos os artigos da GEDOC

Validação de Recuperação (Proof of Restore)

Backup 3-2-1-1-0

A importância dos backups na gestão documental

GEDOC Service — administração técnica de plataformas

Política de gestão do histórico dos documentos

 

Nota editorial e fontes consultadas

Este artigo é informativo e destina-se a organizações que avaliam serviços SaaS em Portugal e na União Europeia. Não constitui aconselhamento jurídico, de cibersegurança ou de continuidade, nem confirma as características de qualquer fornecedor. Requisitos, contratos, riscos e medidas devem ser validados por profissionais competentes.

 

Fontes consultadas em 4 de agosto de 2026:

EUR-Lex — RGPD, artigos 28.º e 32.º

EUR-Lex — Regulamento dos Dados, capítulo VI

CISA — #StopRansomware Guide

NIST SP 800-209 — Security Guidelines for Storage Infrastructure

ENISA — Procure Secure: cloud security service levels

GEDOC — Backups, GEDOC Service e artigos relacionados