Banner must:
- Appear before any non-essential cookies are set
- Present accept and reject options with equal prominence
- Link to full privacy policy and cookie policy
- Allow granular category-level choice (not just accept all / reject all)
- Record consent with timestamp, version, and signal (for audit)

Preference center must:
- Be accessible from footer at any time
- Allow withdrawing consent as easily as giving it
- Persist preferences across sessions (store in first-party cookie or server-side)
- Respect GPC (Global Privacy Control) signal for CCPA opt-out

{
  "user_id": "...",
  "session_id": "...",
  "timestamp": "2024-01-15T10:23:00Z",
  "policy_version": "2.3",
  "signal": "explicit_accept",
  "categories": {
    "strictly_necessary": true,
    "functional": true,
    "analytics": false,
    "marketing": false
  },
  "geo": "DE",
  "ip_hash": "sha256(...)"
}

1. DESCRIPTION OF PROCESSING
   - Purpose(s) of the processing
   - Nature of the processing (collection, storage, sharing, deletion)
   - Scope: data categories, volume, frequency, retention
   - Context: who are the data subjects? Are they vulnerable?
   - Recipients: internal teams, third-party processors, public

2. NECESSITY AND PROPORTIONALITY
   - Is each data element strictly necessary for the stated purpose?
   - Could a less privacy-invasive approach achieve the same outcome?
   - What is the legal basis? Is it proportionate to the risk?
   - What retention period is justified?

3. RISK IDENTIFICATION
   For each risk, assess: likelihood (Low/Medium/High) x severity (Low/Medium/High)
   - Unauthorized access or data breach
   - Inadvertent disclosure to wrong recipients
   - Excessive collection beyond stated purpose
   - Inability to fulfill data subject rights
   - Re-identification of pseudonymized data
   - Discrimination or unfair automated decisions

4. RISK MITIGATION MEASURES
   - Technical: encryption, access controls, pseudonymization, audit logs
   - Organizational: training, DPAs with processors, incident response plan
   - Process: retention schedules, DSR workflow, breach notification procedure

5. RESIDUAL RISK AND SIGN-OFF
   - Residual risk level after mitigations: Low / Medium / High
   - If residual risk remains High: consult supervisory authority before proceeding
   - Sign-off: DPO (if applicable), Legal, Engineering, Product owner
   - Review date: (recommend annually or on significant change)

Subject Access Request (SAR / Right to Know):
- Export all personal data held across: primary DB, data warehouse,
  analytics tools, marketing platforms, support tickets, backups*
- Include: categories of data, purposes, retention periods,
  recipients/third parties, source of data if not collected directly
- Format: machine-readable (JSON/CSV) + human-readable summary
- *Note: you must describe backup data; you are not required to restore
  a backup solely to fulfill a SAR

Erasure / Right to Deletion:
- Delete from primary store, read replicas, analytics, marketing platforms
- Notify all processors and sub-processors
- Exceptions: data held for legal obligation (tax, fraud) may be retained
  with processing restricted; document the exception
- Backups: document policy (e.g., "purged within 90 days as backups rotate")
- Send confirmation to requestor with scope of deletion

Portability (GDPR Art. 20 / CCPA):
- Applies to data the user provided (not inferred data under GDPR)
- Format: structured, commonly used, machine-readable (JSON preferred)
- Must include all user-provided + observed behavioral data

Request tracking minimum fields:
- Request ID, type, date received, requestor identity verified (boolean)
- Date fulfilled / extended / denied, reason if denied, response sent (boolean)

For each table / data category:
1. What is the purpose of this data?
2. Is there a legal minimum retention? (e.g., financial records: 7 years)
3. Is there a legal maximum? (e.g., GDPR's storage limitation principle)
4. When does the retention clock start?
   - Date of collection, last interaction, end of contract, or legal obligation end
5. What deletion action is taken?
   - Hard delete: remove the row entirely
   - Anonymization: replace PII fields with null/hash - retain for analytics
   - Archival: move to cold storage, restricted access, then delete at archive TTL

// Scheduled job (daily or weekly)
function runRetentionPolicy():
    for each retention_rule in retention_schedule:
        records = db.query(
            "SELECT id FROM " + rule.table +
            " WHERE " + rule.clock_column + " < NOW() - INTERVAL '" + rule.period + "'" +
            " AND NOT has_legal_hold"
        )
        for each record in records:
            if rule.action == "delete":
                db.hardDelete(rule.table, record.id)
                auditLog("retention_delete", rule.table, record.id)
            else if rule.action == "anonymize":
                db.anonymize(rule.table, record.id, rule.pii_columns)
                auditLog("retention_anonymize", rule.table, record.id)

Is the destination country on the EU adequacy list?
  YES -> Transfer permitted. No additional mechanism required.
        (Maintain documentation confirming adequacy status.)
  NO  -> Is it an intra-group transfer?
    YES -> Consider Binding Corporate Rules (BCRs)
           - Long approval process; only viable for large multinationals
    NO  -> Use Standard Contractual Clauses (2021 SCCs)
           - Use Module 1 (controller to controller)
           - Use Module 2 (controller to processor) - most common
           - Conduct Transfer Impact Assessment (TIA) for high-risk destinations
           - Implement supplementary measures if TIA shows elevated risk
             (e.g., encryption where processor cannot access keys)