Start Building

Lesson 38: Data Subject Access Request Evidence Packet and Fulfillment Routing for RPG Live-Ops

Lesson 37 established legal-hold and retention exception controls. The next operational gap is DSAR execution: teams know what data exists, but requests still miss deadline because ownership and evidence handoff are inconsistent.

This lesson gives you one DSAR packet format and fulfillment routing lane so support, analytics, and legal owners can complete responses with predictable quality.

Layangan (kite) illustration for DSAR evidence packet and routing lesson

What you will build

By the end of this lesson, you will have:

  1. A dsar_evidence_packet.md template with identity proof, request scope, systems queried, and delivery record
  2. A dsar_fulfillment_routing.md lane map from intake to final response
  3. A response SLA tracker tied to legal-hold and retention states
  4. A release-week check that blocks promotion when DSAR queue risk exceeds your policy threshold

Step 1 - Standardize DSAR intake fields

At request intake, capture only required and verifiable fields:

  • requester ID or account identifier
  • jurisdiction and policy clock start time
  • request type (access, deletion, correction, portability)
  • scope notes (all data vs feature-limited data)

Missing intake structure is the main reason teams restart DSAR processing mid-lane.

Step 2 - Create dsar_evidence_packet.md

Use one packet per request:

field example
dsar_id DSAR-2026-0418-01
request_type access
request_received_at 2026-04-18 10:15 UTC
jurisdiction_clock_days 30
identity_verification_state verified
systems_queried support_db, gameplay_events, warehouse_views
legal_hold_overlap none
retention_exception_overlap none
response_owner privacy operations
delivered_at 2026-04-23 15:05 UTC

Keep this packet immutable after delivery; append updates as timestamped addenda.

Step 3 - Build dsar_fulfillment_routing.md

Define one lane map with explicit owners:

  1. Intake lane — support verifies request structure and identity
  2. Discovery lane — analytics/data owners collect requested records
  3. Policy lane — legal/privacy validates scope and redactions
  4. Delivery lane — support sends package and logs completion evidence

Every lane transition must include:

  • handoff_at
  • owner
  • packet checksum or version marker

Step 4 - Align with legal-hold and retention controls

Before final response:

  • check if request overlaps active legal hold from Lesson 37
  • check if retention exception rules from Lesson 37 alter deletion or disclosure timing
  • log any hold-related limitation in the packet

Do not run DSAR fulfillment as a separate system from hold and retention governance.

Step 5 - Add DSAR SLA risk tracking

Track each open request with:

  • due date
  • current lane
  • blocking dependency
  • risk state (green, yellow, red)

Use these rules:

  • green -> on track with all owner handoffs complete
  • yellow -> one dependency at risk but recoverable within policy window
  • red -> likely breach without escalation or staffing intervention

Step 6 - Connect to release operations

Add one row to launch control packets:

  • open_dsar_red_count
  • oldest_open_dsar_age_days
  • escalation owner

If open red DSAR risk breaches policy, treat release confidence as yellow until recovery steps are assigned.

Common mistakes

Mistake: DSAR evidence spread across chat threads

Fix: Keep one canonical packet and reference it in every lane handoff.

Mistake: Identity verification is implied, not recorded

Fix: Require explicit verification state and timestamp before discovery lane starts.

Mistake: DSAR owners unaware of legal hold overlap

Fix: Add mandatory hold/retention overlap check before delivery.

Pro tips

  • Use stable IDs (DSAR-YYYY-MMDD-NN) for packet searchability.
  • Keep one weekly DSAR readiness review even outside incident periods.
  • Include packet version hash in support macros for audit-ready responses.

Mini challenge

  1. Draft one DSAR packet for an access request involving support and gameplay telemetry.
  2. Simulate one lane handoff delay and mark risk state changes.
  3. Add one escalation rule when oldest_open_dsar_age_days exceeds your threshold.

FAQ

Is DSAR routing only a legal process?

No. It is an operations process with legal checks. Support, analytics, and platform owners must all participate.

Can we answer DSAR requests from only warehouse exports?

Only if your packet proves warehouse coverage is complete for the user scope. Otherwise include source systems.

What if fulfillment conflicts with active legal hold?

Document overlap explicitly, apply jurisdiction rules, and escalate through the policy lane before delivery.

Lesson recap

You now have a DSAR execution model that ties intake, discovery, policy checks, and delivery into one auditable packet. This closes the common gap between governance design and real response operations.

Next lesson teaser

Next lesson: Lesson 39: Cross-Vendor Subprocessor Change Alert Protocol for DPA Drift in RPG Live-Ops adds a vendor notice register, four-lane alert routing, inventory reconciliation with Lesson 36, DSAR template hooks, and launch control counters so subprocessors cannot drift silently.

Related learning