Políticas de retenção de dados e automação: mantenha o que você precisa, exclua o que você precisa

As empresas retêm em média 33% mais dados do que o necessário legalmente, aumentando os custos de armazenamento e a exposição a violações. A retenção de dados é onde convergem a conformidade legal, a otimização de custos e a segurança. Retenha demais e você aumentará sua superfície de ataque. Retenha muito pouco e você violará os requisitos legais de retenção.

Este guia aborda o design da política de retenção, os requisitos legais por tipo de dados e a aplicação automatizada que mantém a conformidade da sua organização sem intervenção manual.

Principais conclusões

• Os períodos de retenção são determinados pela interseção de requisitos legais, necessidades comerciais e obrigações de privacidade
• A aplicação automatizada é essencial --- processos de exclusão manual têm uma taxa de falha de 40%
• Diferentes tipos de dados dentro do mesmo sistema podem ter diferentes períodos de retenção
• As retenções legais devem substituir as políticas de retenção padrão quando um litígio é previsto

---

Requisitos de período de retenção por regulamento

Requisitos Mínimos de Retenção

Retenção fiscal específica do país

---

Projetando um cronograma de retenção

Etapa 1: categorias de dados de inventário

Etapa 2: Atribuir períodos de retenção

Para cada categoria, determine o período de retenção usando esta hierarquia:

1. Mínimo legal: O que a lei exige que você cumpra?
2. Máximo legal: O que a lei exige que você exclua? (Limitação da finalidade do GDPR)
3. Necessidade comercial: por quanto tempo você realmente precisa dela?
4. Tolerância ao risco: Qual é o custo de mantê-lo versus excluí-lo?

O período de retenção é: MAX (mínimo legal, necessidade comercial), mas NÃO MAIS DO que o máximo legal (se aplicável).

Etapa 3: Definir ações de descarte

---

Aplicação de retenção automatizada

Implementação PostgreSQL

-- Retention policy table
CREATE TABLE retention_policies (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    table_name VARCHAR(100) NOT NULL,
    date_column VARCHAR(100) NOT NULL,
    retention_days INTEGER NOT NULL,
    action VARCHAR(20) NOT NULL, -- 'DELETE', 'ANONYMIZE', 'ARCHIVE'
    condition TEXT, -- Optional WHERE clause
    enabled BOOLEAN DEFAULT TRUE,
    last_run TIMESTAMP,
    records_affected INTEGER DEFAULT 0
);

-- Insert policies
INSERT INTO retention_policies (table_name, date_column, retention_days, action, condition) VALUES
('support_tickets', 'closed_at', 1095, 'ANONYMIZE', 'status = ''closed'''),
('recruitment_candidates', 'applied_at', 730, 'DELETE', 'status != ''hired'''),
('session_logs', 'created_at', 90, 'DELETE', NULL),
('newsletter_unsubscribed', 'unsubscribed_at', 365, 'DELETE', NULL),
('audit_logs', 'created_at', 2555, 'ARCHIVE', NULL);

-- Enforcement function
CREATE OR REPLACE FUNCTION enforce_retention_policies()
RETURNS TABLE(policy_id UUID, table_name TEXT, records_affected BIGINT) AS $$
DECLARE
    policy RECORD;
    affected BIGINT;
    query TEXT;
BEGIN
    FOR policy IN
        SELECT * FROM retention_policies WHERE enabled = TRUE
    LOOP
        IF policy.action = 'DELETE' THEN
            query := format(
                'DELETE FROM %I WHERE %I < NOW() - INTERVAL ''%s days''',
                policy.table_name, policy.date_column, policy.retention_days
            );
            IF policy.condition IS NOT NULL THEN
                query := query || ' AND ' || policy.condition;
            END IF;
        ELSIF policy.action = 'ANONYMIZE' THEN
            -- Anonymization requires table-specific logic
            -- This is a simplified example
            query := format(
                'UPDATE %I SET email = ''[email protected]'', name = ''Anonymized'' WHERE %I < NOW() - INTERVAL ''%s days''',
                policy.table_name, policy.date_column, policy.retention_days
            );
            IF policy.condition IS NOT NULL THEN
                query := query || ' AND ' || policy.condition;
            END IF;
        END IF;

        EXECUTE query;
        GET DIAGNOSTICS affected = ROW_COUNT;

        UPDATE retention_policies
        SET last_run = NOW(), records_affected = affected
        WHERE id = policy.id;

        RETURN QUERY SELECT policy.id, policy.table_name::TEXT, affected;
    END LOOP;
END;
$$ LANGUAGE plpgsql;

Agendamento

# Run retention enforcement daily at 3 AM
# /etc/cron.d/retention-enforcement
0 3 * * * postgres psql -d ecosire -c "SELECT * FROM enforce_retention_policies();" >> /var/log/retention-enforcement.log 2>&1

---

Retenções legais

Quando se aplica uma retenção legal

Uma retenção legal suspende as políticas normais de retenção quando um litígio é antecipado, pendente ou em andamento. Todos os dados potencialmente relevantes devem ser preservados independentemente dos cronogramas de retenção.

Implementação

-- Legal hold table
CREATE TABLE legal_holds (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    matter_name VARCHAR(255) NOT NULL,
    description TEXT,
    custodians TEXT[], -- Users whose data is held
    tables_affected TEXT[], -- Tables where retention is suspended
    created_at TIMESTAMP DEFAULT NOW(),
    released_at TIMESTAMP,
    created_by UUID REFERENCES users(id)
);

-- Modified retention enforcement respects legal holds
CREATE OR REPLACE FUNCTION enforce_retention_with_holds()
RETURNS void AS $$
BEGIN
    -- Skip tables under active legal hold
    DELETE FROM session_logs
    WHERE created_at < NOW() - INTERVAL '90 days'
    AND 'session_logs' NOT IN (
        SELECT UNNEST(tables_affected)
        FROM legal_holds
        WHERE released_at IS NULL
    );
END;
$$ LANGUAGE plpgsql;

---

Verificação e Conformidade

Auditoria de retenção mensal

• [] Todas as políticas de retenção são documentadas e atuais
• [] A aplicação automatizada foi executada com sucesso (verifique os registros)
• Não existem dados além do período de retenção (verificação de amostra)
• [] As retenções legais estão ativas para todos os litígios pendentes
• [] Novas categorias de dados receberam períodos de retenção atribuídos
• [] Processadores terceirizados cumprem os requisitos de retenção

---

Perguntas frequentes

O que acontece se mantivermos os dados por mais tempo do que o necessário de acordo com o GDPR?

A retenção de dados pessoais para além do período de retenção necessário viola o princípio de limitação de armazenamento do RGPD (artigo 5.º, n.º 1, alínea e)). As autoridades de supervisão podem emitir multas até 20 milhões de euros ou 4% do volume de negócios anual global. De forma mais prática, o excesso de dados aumenta sua exposição em caso de violação – você é responsável por dados que não deveria ter tido.

Como lidamos com a retenção de cópias de backup?

Os backups complicam a retenção porque contêm instantâneos de dados em momentos específicos. Opções: (1) alternar os backups de acordo com um cronograma alinhado ao seu período de retenção mais longo, (2) criptografar os backups e destruir a chave de criptografia quando a retenção expirar ("fragmentação de criptografia"), (3) aceitar que os backups podem conter dados expirados, mas documentar isso como uma limitação técnica com controles de compensação.

Como implementamos a retenção no Odoo?

Odoo não possui automação de retenção integrada. Implemente-o usando: (1) ações agendadas (cron jobs) que arquivam ou anonimizam registros antigos, (2) módulos personalizados que impõem regras de retenção em modelos específicos, (3) funções em nível de banco de dados para operações em massa. ECOSIRE fornece personalização Odoo para gerenciamento automatizado do ciclo de vida de dados.

---

O que vem a seguir

A retenção de dados é um componente de um programa de governança completo. Combine-o com privacidade desde o projeto para novos sistemas, privacidade de dados de funcionários para dados de RH e gerenciamento de contratos de fornecedores para processadores terceirizados.

Entre em contato com a ECOSIRE para consultoria de implementação e concepção de políticas de retenção de dados.

---

Publicado pela ECOSIRE – ajudando as empresas a gerenciar dados durante todo o seu ciclo de vida.