Quando retencao e eliminacao se aplicam e o que fazer a seguir

Retencao e eliminacao aplicam-se sempre que uma equipa SaaS recolhe, armazena, copia, exporta, analisa, arquiva ou remove dados pessoais. Nao e apenas para pedidos formais de apagamento. Tambem surge em churn de cliente, tickets fechados, offboarding, integracoes, logs de produto e ciclos de backup.

No GDPR, dados pessoais devem ser guardados pelo menor tempo possivel para a finalidade, com limites de eliminacao ou review. Operacionalmente, a equipa precisa de saber que sistemas estao no scope, quem decide, que acao ocorre, que excecao se aplica e que evidencia prova a execucao.

Quando se aplica em SaaS

Comeca quando um workflow cria ou recebe dados pessoais e continua ate eliminacao, anonimizacao, restricao, arquivo justificado ou expiry documentado. Onboarding, features, vendors, account closure, tickets, disputas, legal holds, customer diligence, exports e backups sao pontos de controlo.

Quando a resposta varia

Nem tudo exige a mesma eliminacao. Alguns dados devem ser apagados cedo, outros anonimizados, outros retidos por fiscalidade, fraude, security, contrato ou claims, e outros ate backup expiry. A decisao deve ser por categoria e sistema.

Passo 1: dados e finalidade

Comece pela categoria: conta, autenticacao, eventos de produto, suporte, billing, security logs, candidatos, vendors e reports podem ter finalidades diferentes. Pergunte que finalidade justifica o tratamento, que sistemas contem os dados e se menos dados ou dados anonimos chegam.

Passo 2: trigger

Um periodo nao funciona sem evento inicial. Exemplos: fim de contrato, workspace closure, final invoice, ticket closure, applicant rejection, offboarding, incident closure, legal hold release, vendor termination ou backup rotation. O trigger deve gerar a mesma data para todas as equipas.

Passo 3: acao

A acao pode ser hard deletion, purge programado, anonimizacao, restricao, arquivo, suppression record, vendor deletion, backup expiry ou retencao sob excecao documentada. Promessas a clientes devem refletir a realidade tecnica.

Passo 4: owners

Defina owners para regra, sistema ou vendor, detecao do trigger, acao, aprovacao de excecoes, comunicacao e evidencia. O modelo pode ser leve, mas deve estar claro antes de auditoria, customer review ou launch.

Passo 5: evidencia

Evidencia pode incluir regra, mapa de sistemas, request, approval, deletion log, output de anonimizacao, vendor confirmation, backup note e completion date. A politica mostra intencao; a evidencia mostra execucao.

O que fazer a seguir

Escolha um workflow com pressao real: encerramento de conta, pedido de apagamento, tickets de suporte, candidatos ou vendor offboarding. Liste dados e sistemas, escreva o trigger, defina acao e excecoes, atribua owners, teste um exemplo e guarde evidencia. Depois repita.

FAQ

Qual e o objetivo pratico?

Guardar dados pessoais apenas com finalidade ou obrigacao justificada, e depois elimina-los, anonimiza-los, restringi-los, arquiva-los ou revê-los por um workflow controlado.

Quando se aplica a equipas SaaS?

Quando recolhem, armazenam, copiam, exportam, analisam, arquivam ou eliminam dados pessoais, incluindo produto, suporte, billing, logs, vendors e backups.

O que documentar primeiro?

Um workflow de alto risco com categorias, sistemas, trigger, owner, acao, excecoes e evidencia.