DSAR Workflow Design for Small SaaS Teams Without a Legal Ops Function

Small SaaS teams usually treat DSARs — data subject access requests — as ad hoc support tickets. Someone emails asking for their data, a support agent forwards it to engineering, engineering queries the database manually, and someone pastes the results into a reply. No record of the request. No audit trail. No way to prove a deletion was actually complete.

That approach fails the first time a regulator asks for evidence of your process. It also fails at low volume — three simultaneous requests with a 30-day response clock is enough to put a two-person engineering team behind on product work. This is not legal advice. Verify your obligations with qualified counsel.

The state machine approach: make DSAR a pipeline, not a ticket

The core mistake is treating each DSAR as a unique event. A DSAR is a predictable process with defined stages. Build it as a state machine from the start.

Minimum states:

• Received — request logged with timestamp and source channel
• Identity verified — requestor confirmed to match the data subject
• Scoped — data domains identified, systems mapped
• Fulfilled — response sent (access package, deletion confirmation, or rejection with legal basis)
• Closed — retention period for request record confirmed, archived

Every transition should be timestamped and tied to a named responsible party. If your company ever faces a regulatory inquiry, the audit log answers "did you process this request on time and who handled it" in one query.

For tooling: a Notion database, a Linear project, or even a Google Sheet with locked columns works for teams under 50K users. At higher volume, a lightweight case management table in your own database is preferable — you own the audit log and it cannot be accidentally deleted.

SLA design: what the laws actually require

CPRA gives California residents 45 days with a 45-day extension permitted with notice. VCDPA and CTDPA give 45 days with a 45-day extension. GDPR gives 30 days with a 60-day extension for complex cases, with notice required.

The practical SLA I recommend for small SaaS teams: 30 days internal target, 45-day statutory clock. The 15-day buffer absorbs engineering delays (your user ID is in three systems and one of them is a legacy billing tool from a previous provider) without hitting the statutory limit.

Define these in your SLA table before the first DSAR arrives:

For rejection criteria — not every request is valid. A request from someone who cannot verify they are the data subject, a request that is "manifestly unfounded or excessive" under GDPR, or a deletion request where legal holds apply — these require a documented rejection with the legal basis cited. Create template rejection notices now, before you need them under time pressure.

Identity verification: the step most teams skip

Responding to a DSAR without verifying the requestor's identity is a data breach waiting to happen. If someone submits a request using another user's email address and you send them that user's data, you have violated the privacy law you were trying to comply with.

Verification approach by risk level:

• Low risk (own-account access requests): Email verification via a signed magic link sent to the email address on the account. If the requestor controls that email, they are likely the data subject.
• Higher risk (deletion requests, large data exports): Add a secondary factor — last 4 digits of payment method on file, account creation date, or a support ticket submitted from within the authenticated session.
• Failed verification: Do not reject, do not fulfill. Send a notice explaining what additional verification is needed. Document the attempt and the outcome.

One important nuance: if your product allows users to use organizational email addresses where the IT admin controls the inbox, a magic link is weaker verification than it appears. Consider whether you need an in-app verification flow in addition to email.

Engineering integration: where deletion requests actually break

The hardest part of DSAR compliance is not the policy — it is the deletion. Most SaaS products store user-identifiable data in more places than engineering realizes until someone has to enumerate them.

Common places data lives that deletion scripts miss:

• Backups — your nightly Postgres dump contains data you just deleted from the live database. You need a documented retention policy for backups and a process for handling deletion requests against backup data.
• Third-party integrations — the user's email address is in your Intercom contacts, your Mailchimp list, your Stripe customer record, and your analytics events. Deletion from your DB does not delete it from those systems.
• Logs — application logs, error tracking (Sentry, Datadog), and access logs may contain email addresses or user IDs. These often have their own retention periods.
• ML training data — if you have used user-generated content to train or fine-tune a model, deletion becomes architecturally complex. You need to decide and document your approach before this comes up.

Build a data map — a simple spreadsheet or Notion table — listing every system that stores user-identifiable data and the mechanism for deletion in each. This document is both a compliance artifact and a practical runbook for engineers handling deletion requests.

For access requests (the user wants a copy of their data, not deletion), build an export script per data domain that produces a machine-readable format. JSON works. Include the data categories in a cover document so the user understands what they received.

What to build in the first sprint

If you are starting from zero, this is the minimum viable DSAR pipeline:

1. Intake form — a public-facing form at /privacy/request or a dedicated email alias ([email protected]) that captures: request type, name, email address, and account identifier if applicable. Log every submission automatically.
2. Verification template — one email template that sends a magic link or asks for secondary verification, with a 7-day expiry.
3. Request tracking — a simple case record with the state machine fields above, SLA due date calculated at intake, and assignee.
4. Deletion runbook — a step-by-step checklist for engineers covering every data store in your map. Checkbox per system, signature field for the engineer who ran it, timestamp.
5. Response templates — one for fulfilled access requests, one for confirmed deletions, one for rejections, one for extensions.

None of this requires legal ops. It requires a support person who owns intake and verification, an engineer who builds and runs deletion scripts, and someone with authority to make the call on rejections. At most early-stage SaaS companies, that is three people who already exist — they just need a documented process.

Use the US State Privacy Policy Generator to draft the privacy notice language that references your DSAR process. The policy and the operational workflow need to be consistent — if your policy says 30 days and your SLA table says 45, that is a gap a regulator will notice.

The goal is to treat the first real DSAR as a boring operations event, not a fire drill. Build the pipeline before you need it.