Data Subject Access Request (DSAR)
Term 54 of 68 in the ERPStack technical glossary
What is Data Subject Access Request (DSAR)?
A Data Subject Access Request (DSAR) is a legal right granted to individuals under GDPR, CCPA, and equivalent privacy laws to request that an organization provide, correct, or delete all personal data held about them within a statutory deadline — 1 month under GDPR Article 12(3), 45 days under California Civil Code 1798.130.
Data Subject Access Request (DSAR) at a glance
- Legal clock
- GDPR Article 12(3) — 1 month to respond, extendable by 2 further months where justified
- Scope problem
- 1 person may exist across many tables, backups, logs and third-party processors
- Engineering answer
- A subject-identity index so the search is 1 query rather than a manual hunt
- Conflict to resolve
- Erasure requests against WORM records a separate regulation requires you to retain
- Built with
- 1 subject identifier referenced by every personal-data table in PostgreSQL 18, exports built in Next.js 16 with Drizzle ORM 0.45, RBAC and SSO gating the operator, Sentry payloads scrubbed
- Numbers that matter
- Article 12(3): 1 month, extendable by 2; 1 query instead of a hunt across 20 tables; 4 places data hides — tables, extracts, logs, backups
- Where the data hides
- A CRM, the ERP on PostgreSQL 18, ClickHouse extracts, MongoDB Atlas collections, Redis caches, Sentry payloads and AWS backups
- Commonly paired with
- Row-Level Security and RBAC over PostgreSQL 18, SSO on the operator path, an Immutable Audit Trail, Drizzle ORM 0.45 export queries, Sentry payload scrubbing, ClickHouse extract coverage and documented AWS backup retention
- Coverage checklist
- 6 surfaces to cover — PostgreSQL 18 tables, ClickHouse extracts, Sentry payloads, AWS backups, a CRM, and any processor acting for you
- Two statutory clocks
- GDPR Article 12(3) gives 1 month, extendable by 2 further months. California Civil Code 1798.130 gives 45 days, extendable once by another 45 with notice inside the first period.
- Who receives them
- retail and healthcare records first, then finance, insurance and legaltech files held under a separate retention rule.
- Processors that answer too
- Every SaaS acting for you — a CRM, Monday.com Work OS boards, Zoho Creator apps, HubSpot lists — runs on the same clock as the ERP on PostgreSQL 18.
How Data Subject Access Request (DSAR) works in production
The ERPStack approach to Data Subject Access Request (DSAR)
We build automated DSAR pipelines using PostgreSQL stored procedures that join across all relevant tables by user_id, package the result as a GDPR-compliant JSON export, and deliver it via encrypted email within 48 hours.
Frequently asked questions about Data Subject Access Request (DSAR)
What is a Data Subject Access Request?
A request from an individual to see, correct, export or erase the personal data an organisation holds about them. Under GDPR Article 12(3) an Access Request must be answered within 1 month, extendable by 2 further months where the request is complex. The deadline is what makes it an engineering problem: a manual search across systems rarely completes reliably inside it.
Why are DSARs technically difficult?
Because personal data spreads. An Access Request must cover primary tables, denormalised copies, analytics extracts, application logs, backups and any processor acting on your behalf. Systems that duplicate personal data for convenience turn a routine request into an investigation. Keeping 1 authoritative record with references elsewhere is what makes the search tractable, and that is a schema decision made years earlier.
How do you handle erasure against retained records?
By resolving the conflict deliberately, per record class. An Access Request for erasure does not override an independent legal obligation to retain — accounting records and regulated electronic records are common examples. The correct response documents which data was erased, which was retained, and the legal basis for retaining it, rather than silently doing one or the other and hoping nobody asks.
What does ERPStack build to make DSARs routine?
A subject-identity map and an export path. Every table holding personal data references 1 subject identifier, so an Access Request resolves through a query rather than a search; export produces a structured file; erasure runs through a documented path that records what was removed and what was retained under which basis. Built in from the start this is a small feature — retrofitted, it is a project.