# ADR-019 — LGPD/privacidade como programa (não só criptografia)

| Campo | Valor |
|---|---|
| **Status** | Aceito (2026-10-20) |
| **Data** | 2026-10-14 |
| **Plano de origem** | `wiki/plan/17-dados-abertos-lgpd-governanca.md` |
| **Relacionadas** | ADR-017, ADR-020, ADR-018 |

## Contexto

O plano trata LGPD apenas como **criptografia de PII** (cast `encrypted`). Um CMS governamental
lida com dados pessoais (ouvidoria, cadastros, contatos) e precisa de um **programa** de
privacidade: base legal, direitos do titular, retenção, registro de operações, incidentes e
transparência. Sem isso, há risco legal e reputacional.

## Decisão

- **Classificação de dados** por campo/entidade: público · interno · pessoal · sensível
  (dirige cifra, log e retenção).
- **Base legal e finalidade** por tratamento; **ROPA** (registro de operações) como **dado**
  (tabela simples), não documento solto.
- **Direitos do titular (DSAR)**: acesso, correção, eliminação e portabilidade — fluxo no CMS
  com prazo, trilha de auditoria e resposta ao titular.
- **Retenção e descarte**: prazo por entidade; **expurgo agendado** (Scheduler nativo) +
  `legal hold`; nunca `DROP` de histórico (ADR-017).
- **Privacy by design/default**: minimização (ADR-017), cifra de PII (cast nativo), e
  **auditoria de acesso a dado pessoal**.
- **Consentimento onde couber** (cookies/analytics) + banner acessível; **analytics
  privacy-first** (sem Google Analytics; medição agregada própria ou cookie-less).
- **Incidentes/breach**: runbook + notificação à **ANPD** e titulares; evidência via logs/auditoria.
- **DPIA** para tratamentos de alto risco (ex.: ouvidoria); **encarregado (DPO)** com canal
  público; **transferência internacional** e subprocessadores documentados.
- **Sem** suíte externa de privacidade: nativo (cast, auditoria, scheduler, páginas legais).

## Justificativa (alternativas descartadas)

- **Só criptografar PII** — descartada: não cobre direitos, retenção, ROPA nem incidentes.
- **Plataforma de consentimento/DPO de terceiro** — descartada: dependência e custo; o núcleo
  é simples de implementar.
- **Analytics de terceiros** — descartada: privacidade e zero CDN.

## Consequências

**Positivas**
- Conformidade verificável (base legal, direitos, retenção, incidentes) e transparência.
- Reaproveita `Audit`, `encrypted`, `Scheduler` — sem dependência nova.

**Custos / negativas**
- Exige governança (DPO, ROPA, prazos) e disciplina editorial.
- Expurgo agendado precisa de cuidado com histórico/auditoria.

## Exemplo mínimo (comparativo)

```php
// ❌ LGPD = só cifrar o campo
protected $casts = ['cpf' => 'encrypted'];

// ✅ Classificação + retenção + auditoria de acesso
// schema: campo classificado 'pessoal'; entidade com retencao_dias
// scheduler: expurgarOuvidoriaAntiga()  // respeita legal hold, preserva auditoria
// audit: registrarAcessoPessoal($ator, $registro)  // quem viu dado pessoal, quando
// páginas: /privacidade, /acesso-a-informacao, /encarregado
```

## Verificação

- Campo pessoal é cifrado, classificado e tem prazo de retenção aplicado por job.
- Pedido de titular (acesso/correção/eliminação) é executado com trilha de auditoria.
- Acesso a dado pessoal gera log; incidente tem runbook e canal ANPD.
- Nenhum analytics de terceiros; banner de consentimento acessível quando houver cookies.

## Referências

- Lei 13.709/2018 (LGPD); ANPD; `wiki/plan/17-dados-abertos-lgpd-governanca.md`.
