Consent Withdrawal

TRIGGER: User clicks withdrawal toggle for a specific purpose
  │
  ├─► Step 1: Client-Side
  │     ├─ Display confirmation dialog:
  │     │   "Withdraw consent for [purpose name]?"
  │     │   "This will stop [specific processing description]."
  │     │   "You can re-enable this at any time."
  │     │   [Cancel] [Withdraw]
  │     │
  │     └─ User clicks [Withdraw]
  │
  ├─► Step 2: API Call
  │     PUT /api/v1/consent/preferences/{subject_id}
  │     Body: { decisions: [{ purpose_id: "pur_analytics_01", decision: "withdrawn", mechanism: "toggle_switch" }] }
  │
  ├─► Step 3: Backend Processing (within 100ms)
  │     ├─ Create ConsentDecision record (decision: "withdrawn")
  │     ├─ Validate request (subject exists, purpose exists, consent was previously granted)
  │     ├─ Update consent state cache (Redis/in-memory)
  │     └─ Return success response to client
  │
  ├─► Step 4: Cascading Effects (async, within 1 hour)
  │     ├─ Dispatch withdrawal events to message queue (Kafka/RabbitMQ/SQS)
  │     ├─ Each downstream system receives withdrawal notification:
  │     │
  │     │   Purpose: "Service Improvement Analytics" (pur_analytics_001)
  │     │   ├─ Stop analytics SDK data collection for this user
  │     │   ├─ Remove user from analytics cohorts
  │     │   └─ Flag existing analytics data for review/deletion
  │     │
  │     │   Purpose: "Product Update Emails" (pur_marketing_002)
  │     │   ├─ Remove user from email marketing lists
  │     │   ├─ Add user to suppression list
  │     │   ├─ Cancel any scheduled email campaigns for this user
  │     │   └─ Confirm with email service provider (ESP)
  │     │
  │     │   Purpose: "Industry Benchmarking" (pur_benchmarking_003)
  │     │   ├─ Stop data sharing with Datalytics Partners Ltd.
  │     │   ├─ Notify Datalytics Partners Ltd. via API
  │     │   ├─ Request confirmation of processing cessation
  │     │   └─ Flag shared data for deletion per DPA terms
  │     │
  │     └─ Log all propagation events with status tracking
  │
  ├─► Step 5: Downstream Acknowledgment (within 24 hours)
  │     ├─ Each downstream system sends acknowledgment
  │     ├─ System monitors for missing acknowledgments
  │     ├─ Escalation workflow for unacknowledged withdrawals:
  │     │   ├─ T+1 hour: Automated retry
  │     │   ├─ T+4 hours: Alert to engineering team
  │     │   └─ T+24 hours: Escalate to DPO
  │     └─ All acknowledgments logged in propagation table
  │
  └─► Step 6: User Confirmation
        ├─ UI updates: toggle shows "off" state
        ├─ Confirmation message: "Consent withdrawn. Processing will stop within 24 hours."
        ├─ Confirmation email sent to user
        └─ Consent receipt updated and available for download

{
    "notification_type": "consent_withdrawal",
    "subject_reference": "hashed_subject_id",
    "purpose_id": "pur_benchmarking_003",
    "withdrawal_timestamp": "2026-03-14T10:30:00Z",
    "required_action": "cease_processing",
    "action_deadline": "2026-03-15T10:30:00Z",
    "acknowledgment_required": true,
    "controller": "CloudVault SaaS Inc."
}

{
    "acknowledgment": true,
    "received_at": "2026-03-14T10:30:05Z",
    "action_status": "processing_cessation_initiated",
    "estimated_completion": "2026-03-14T12:00:00Z"
}