Completions

For chief privacy officers + DPOs + regulatory counsel

OneTrust runs the request portal. The customer data lives in thirty source systems. The data team pulls from each one by hand.

OneTrust, DataGrail, TrustArc, Securiti, BigID, Transcend, WireWheel, Ketch, Osano ship the customer- facing DSAR workflow primitive. They do not have native connectors to all 30 source systems a 200-location operator runs. The data team manually collects customer data from each system on every request. Manual pulling at 200-location scale is what makes operators miss the 30-day GDPR + 45-day CCPA SLAs. The versioned customer- history substrate connects the workflow to the data.

By Jay Christopher11 min read

What this gets you

  • One export answers any DSAR request type — access, export, rectification, deletion, portability. The versioned customer-history substrate pre-computes the cross-system customer dataset; the response generator queries the substrate rather than re-collecting from 30 source systems per request.
  • Cross-system data lineage on every field — every field in the DSAR response traces to its source-system-of-record with timestamp and version metadata. Regulator audit responses pull from the lineage substrate directly.
  • Cross-vertical retention conflict resolution — HIPAA 6-year retention conflicts with GDPR right-to-deletion; FINRA retention conflicts with CCPA right-to-deletion. The response generator evaluates per-record retention rules against the deletion request and produces partial-deletion responses with audit-trail-grade explanation.
  • Identity-verification gate— every DSAR request verifies the customer identity through a tiered authentication flow before the substrate query fires. Verification tiers tune per request type (deletion stricter than access).
  • GDPR 30-day + CCPA 45-day + per-state SLA tracking — SLA timers track per request per regulatory regime. SLA-at-risk requests escalate to the privacy team. International coverage extends to EU + UK + Brazil + India per-jurisdiction SLAs.

Thirty source systems, one DSAR clock

A 200-location operator handles 40-80 DSAR requests per month across GDPR, CCPA, and per-state privacy regulations. The privacy team runs OneTrust for the customer-facing request portal. Customers submit requests through the OneTrust intake; OneTrust handles identity verification, SLA tracking, templated communications, and the final response packaging.

Behind OneTrust the customer data lives in 30-plus source systems — POS at each franchisee, CRM at the parent and at some franchisees, ESP, SMS provider, push channel, loyalty platform, ecommerce site, booking system per banner, GBP, three review platforms, call-tracking, foot-traffic provider, paid-ad audience platforms on Google + Meta + TikTok, behavioral analytics, the identity graph, the customer-data warehouse, and a long tail of franchisee-owned integrations the parent does not fully inventory.

When a request lands, the privacy team forwards to the data team. The data team opens a checklist of 30 systems. The team queries each one for the customer identifier. Some systems support API lookup; some require SQL queries against a replica; some require an export request to the franchisee that owns the system; some require manual login because nobody has automated the export. The 200-franchisee long tail takes the most time. The combined effort runs 4-8 hours per request before the response packaging step. At 60 requests per month the data team spends 240-480 hours monthly on DSAR collection alone. Two requests miss the GDPR 30-day SLA in the same month. The privacy officer files a delay notification with the supervisory authority.

The versioned customer-history substrate pre-computes the customer dataset across every system. The customer-data-orchestration emit-change pipeline broadcasts every customer change to the version store in real time. When a DSAR request lands, the response generator queries the substrate. One query returns the customer dataset across every source system with field-level lineage. The data team time per request drops from 4-8 hours to 10-20 minutes for review. SLA misses go to zero.

One export answers any DSAR type. Access requests return the dataset. Export requests return the dataset in a portable format. Rectification requests update the source-of-record and propagate the change through the versioning emit-change pipeline. Deletion requests evaluate per-record retention rules and produce a partial-deletion response where regulatory retention conflicts the deletion request. Portability requests format the response per the receiving-controller schema.

What is in market — and what each category leaves to you

The DSAR workflow primitive is mature. The versioned customer-history substrate that connects the workflow to the data at multi-location scale is operator-side architecture.

Enterprise privacy management — OneTrust, DataGrail, TrustArc, Securiti, BigID, Transcend, WireWheel, Ketch, Osano

Excellent at the customer-facing DSAR workflow primitive — request portal, identity verification, SLA tracking, response packaging, audit trail. Pre-built connectors to common SaaS sources. The per-franchisee-owned system connector coverage at 200-location scale and the versioned customer-history substrate that pre-computes the cross-system dataset are operator-side architecture above the workflow primitive.

GDPR / CCPA specialists — Privado, Ethyca, Privaini, Compliance.ai

Strong at GDPR-specific and CCPA-specific compliance workflows including data-mapping, privacy-impact assessments, vendor-risk management. The DSAR response generation at multi- location scale plus cross-vertical retention conflict resolution sit downstream of the privacy- program primitives.

DSAR automation — Sourcepoint, Cassie, PrivacyOps, RecollectiveAI

Strong at DSAR-workflow automation with extensible connector frameworks. The per-franchisee-owned system long-tail coverage at 200-location scale plus the versioned-history substrate that closes the SLA-miss gap are operator-side architecture on top of the workflow.

Industry-specific privacy — Veeva (healthcare / pharma DSAR), MetricStream (financial)

Strong at vertical-specific DSAR with regulatory retention rule libraries (HIPAA in Veeva, FINRA retention in MetricStream). The cross-vertical retention conflict resolution at operators spanning multiple verticals sits at the intersection of multiple vertical platforms.

The 30-system checklist the data team works on every Wednesday

The status quo at most multi-location operators running DSAR at scale. The data team opens the checklist on every DSAR request. The Wednesday DSAR queue runs 6-10 hours. Two requests miss the GDPR 30-day SLA per quarter. The privacy officer files the delay notification. The versioned substrate eliminates the checklist.

The pipeline, end to end

  1. Position in the 7-axis customer-graph pipeline. Ingest (behavioral-signal-ingestion) + Resolve (identity-resolution) + Version (this skill) + Compute-LTV (ltv-math-primitives) + Cohort (behavioral-cohort-computation) + Subscription-Ingest + Emit-Change (customer-change-event-emission). The Version axis is the substrate the Emit-Change axis writes into and the DSAR response queries out of.
  2. Versioned-history schema. Per-customer record per source-system carries create + update + delete event versions with field- level diffs, source-system-of-record reference, ingest timestamp, adapter version, and lineage metadata. The schema supports point-in-time queries for any historical state.
  3. Real-time write through the customer-data- orchestration emit-change pipeline. Every customer change event broadcast by the Emit- Change axis writes a new version to the versioned- history store. The version store sees the same event stream as every other downstream consumer.
  4. DSAR request intake plus identity verification. Customer submits the request through the OneTrust or equivalent portal. Identity verification runs through a tiered authentication flow — email- plus-account-credential for access requests; email- plus-account-credential-plus-government-ID for deletion requests; the verification tier tunes per request type and per regulatory regime.
  5. Cross-system substrate query. Verified request triggers a single query against the versioned-history substrate. The query returns the full customer dataset across every source system the operator runs with field-level lineage. No 30-system manual collection; the substrate is the source of truth.
  6. Per-request-type response generation. Access requests return the dataset as-is. Export requests format per the portability schema (JSON + CSV + per-regulation specific formats). Rectification requests update the source-of-record through the customer-data-orchestration emit-change pipeline. Deletion requests evaluate per-record retention rules. Portability requests format per the receiving- controller schema.
  7. Cross-vertical retention conflict resolution. HIPAA 6-year retention conflicts with GDPR right-to- deletion; FINRA 3-7 year retention conflicts with CCPA right-to-deletion. Per-record retention rules evaluate against the deletion request and produce a partial-deletion response. Records the retention covers stay; records outside the retention requirement delete. The customer sees an audit-trail-grade explanation of which records remained and why.
  8. Per-jurisdiction SLA tracking. GDPR 30-day SLA, CCPA 45-day SLA, per-state US laws, UK GDPR, Brazil LGPD, India DPDP. Per-request SLA timer starts at intake. SLA-at-risk requests escalate to the privacy team. SLA breach triggers regulatory delay notification workflow.
  9. Per-franchisee-owned system long-tail coverage. The version store ingests from the broader marketing- data-integration pipeline. The per-source adapter pattern extends the platform connector coverage to the long-tail franchisee-owned systems. The DSAR response sees the long-tail systems through the substrate rather than through manual queries.
  10. AI-generated output handling. AI-generated content that references the customer (review responses, personalized email subject lines, personalized landing-page hero) ingests to the version store as a derivative output of the customer record. DSAR deletion propagates to AI-generated outputs through the customer-data-orchestration tombstone event.
  11. Regulator-grade audit trail. Every DSAR request stores request intake timestamp, verification outcome, substrate-query results, per- request-type response, retention-rule evaluations, final response delivery timestamp, customer acknowledgment if any. Audit trail queryable per regulator per time period per request type.
  12. ROI measurement. Hours-per-DSAR-request pre vs post deployment (target 4-8 hours pre / 10-20 minutes post). SLA-miss rate pre vs post (target zero). Privacy-team headcount requirement vs DSAR volume growth. Regulator delay notifications filed per quarter. Fines avoided attribution against the pre-deployment baseline rate.
  13. Integration with the compliance-mechanic cluster. The DSAR response generation shares substrate with the cross-agent marketing-compliance-software overlay. Per-vertical retention libraries come from the same rule-extraction pipeline as the per-vertical-schema-validation libraries on master- record and the per-vertical-compliance-overlay on the AI-agent fleet. One regulatory substrate, three consumers.

Frequently asked

What is DSAR software?

DSAR (Data Subject Access Request) software handles the customer-side privacy workflow for GDPR, CCPA, and per-state privacy regulations — accept the request from the customer, verify the customer identity, route the request to the operator data team, collect the customer data from every system that holds it, compile the response, and deliver back to the customer within the regulatory SLA (30 days under GDPR, 45 days under CCPA). Enterprise DSAR platforms include OneTrust, DataGrail, TrustArc, Securiti, BigID, Transcend, WireWheel, Ketch, Osano. GDPR/CCPA specialists include Privado, Ethyca, Privaini. The workflow primitive is mature. The versioned customer-history substrate that connects the workflow to the actual customer data is operator-side architecture.

Why does workflow-only DSAR software fail multi-location operators?

A 200-location operator has customer data in 30-plus source systems — POS, CRM, ESP, SMS provider, push channel, loyalty platform, ecommerce, booking system, GBP, review platform, call-tracking, foot-traffic provider, paid-ad audience platforms, behavioral analytics, identity-graph, and the long tail of franchisee-owned integrations. OneTrust and DataGrail manage the customer-facing workflow well — the request portal, the identity-verification step, the SLA tracking, the response packaging. They do not have native connectors to all 30 source systems. The data team manually pulls customer data from each system on every DSAR request. Manual pulling at 200-location scale across 30 source systems for the volume of monthly DSAR requests is what makes operators miss the SLA.

How is this different from OneTrust, DataGrail, TrustArc, Securiti, BigID, Transcend, WireWheel, Ketch, or Osano?

Those platforms are excellent at the customer-facing DSAR workflow primitive. They ship the request portal, the identity verification, the SLA tracking, the response packaging, the audit trail. The versioned customer-history substrate that pre-computes the customer dataset across every system that holds the customer data, the cross-system data lineage that traces every field to its source-system-of-record, the per-franchisee-owned system connector pattern that extends the platform connector coverage to the long-tail franchisee systems, the cross-vertical retention conflict resolution (HIPAA mandates 6-year retention for some records that GDPR right-to-deletion would otherwise delete; FINRA mandates retention conflicting with CCPA), and the integration with the broader 7-axis customer-graph pipeline are operator-side architecture on top of the workflow primitive.

How does versioned customer history support DSAR response?

The customer-graph agent maintains a versioned history of every customer record across every source system. Versions track create + update + delete events with full field-level diffs. When a DSAR request lands, the response generator queries the versioned history rather than re-collecting from every source system. One export answers any DSAR request — access, export, rectification, deletion, portability — by querying the versioned substrate. The substrate refreshes through the customer-data-orchestration emit-change pipeline that broadcasts every customer change to the version store in real time.

How does this fit into the 7-axis customer-graph pipeline?

The customer-data-graph agent owns seven axes — Ingest (behavioral-signal-ingestion), Resolve (identity-resolution-deterministic-probabilistic), Version (this skill — versioned-customer-history), Compute-LTV (ltv-math-primitives), Cohort (behavioral-cohort-computation), Subscription-Ingest (subscription-billing-ingestion), and Emit-Change (customer-change-event-emission). The Version axis is the substrate the Emit-Change axis writes into and the DSAR response queries out of. Together with Ingest and Resolve the three form a 3-skill I/O Pipeline triple on customer-graph (Ingest → Resolve → Archive). The I/O Pipeline is now 4 of 8 3-skill bundles in arc — 50 percent of 3-skill bundles — confirming I/O Pipeline as the dominant 3-skill bundle architecture.

How do you handle cross-vertical retention conflicts in DSAR response?

A multi-vertical operator running healthcare + financial-services + retail locations faces conflicting retention requirements. HIPAA mandates 6-year retention of healthcare records that GDPR right-to-deletion would otherwise delete. FINRA mandates 3-7 year retention of financial records that CCPA right-to-deletion would otherwise delete. The DSAR response generator evaluates per-record retention rules against the deletion request and produces a partial-deletion response — records the regulatory retention covers stay; records outside the retention requirement delete. The customer sees an audit-trail-grade explanation of which records remained and why. The compliance review queue handles edge cases where multiple regulations disagree.

Hire the agent that owns the versioned-history substrate

The customer-data-graph agent owns the 7-axis pipeline — Ingest + Resolve + Version + Compute-LTV + Cohort + Subscription-Ingest + Emit-Change — sitting on top of whichever DSAR workflow platform (OneTrust, DataGrail, TrustArc, Securiti, BigID, Transcend, WireWheel, Ketch, Osano) you license downstream. Versioned customer history with field-level lineage + cross-system substrate query + cross-vertical retention conflict resolution + per-jurisdiction SLA tracking + regulator-grade audit trail.

Hire the customer-graph agent

We scope on the call and send a private checkout link after.

Related reading: Customer data orchestration · Runtime customer cohorts · Multi-source ingestion