Privacy & Consent

💼 Business Context

• Consent enforcement at ingestion isn't sufficient alone — this ensures stored historical data also respects consent changes made after storage
• Directly reduces regulatory risk under GDPR, CCPA, and DPDP
• Owned jointly by Legal/Privacy and Data Governance

🔌 Technical Overview

Every stored event retains its consent_basis field from ingestion. When consent is withdrawn after the fact, a scheduled job updates the stored consent state so that any future query respecting purpose-based access — enforced the same way as Policies & Entitlements — correctly excludes that customer's data from marketing-purpose queries going forward, even though the historical event still exists for legitimate purposes like fraud analysis.

💾 Consent State Update

{
  "customer_key": "cust_004821",
  "consent_basis": { "marketing": false, "analytics": true },
  "updated_at": "2026-08-01T12:00:00Z",
  "reason": "preference_center_withdrawal"
}

🔗 Integration Points

• Consent Enforcement (Ingestion Layer) — first enforcement point, at the edge
• Governance & Security's policy engine — purpose-based query-time filtering
• Preference center — source of consent state changes
• Query & Analytics Engine — respects consent_basis on every purpose-tagged query

🧰 Services Consumed

• Owning microservice — Cxos.Foundation.Api (see the Full Application Service Map)
• Database — ADLS Gen2 (Iceberg) + Azure Database for PostgreSQL (policy/retention state)

⚠️ Non-Functional Considerations

• Scale: consent state is a small, frequently-read field per customer — well within normal query patterns
• Latency: consent updates from the preference center propagate to enforcement within minutes
• Reliability: consent state changes are versioned, so historical "what was consent at time X" questions remain answerable
• Security/Privacy: this is itself the core privacy control the rest of the platform's compliance posture depends on

🎯 Enterprise Example

A customer withdraws marketing consent. Even though their historical events remain in the lakehouse for legitimate analytics and fraud-prevention purposes, every marketing-purpose query from that point forward automatically excludes them — without any team needing to manually update a suppression list.