Skip to main content
DSAR Fulfilment Workflow Under the DPDP Act | Aizzentec — page loaded
Phase 3 enforcement: 13 May 2027. The runway is now.Speak to Aizzentec +91 8220 359 506
Operational

Building a DSAR fulfilment workflow that scales

From request intake to identity verification to the 90-day SLA. The five-stage workflow used by mature programmes.

Operational12 min read
By Praveen Kumar, Practice Leader — Risk, Cyber and AnalyticsCA, CISA, CEH, CDPSE, CFEPublished Updated

The five stages

Every operational DSAR programme has the same five stages, however differently they're labelled:

  1. Intake
  2. Identity verification
  3. Discovery and dependency mapping
  4. Response drafting and approval
  5. Delivery and audit

Stage 1: Intake

Multiple intake channels — web form, in-app self-service, email, customer support escalation, postal — all converge into a single ticket queue with a unique reference number. The reference is the Data Principal's tracking ID and your case ID throughout.

Capture at intake: which right is being exercised (access / correction / erasure / grievance), the Data Principal's stated identifier (email, account ID), the date received, and any context they've provided.

Stage 2: Identity verification

You must verify the requester is the Data Principal. Verification approaches in order of strength:

  • Authenticated session (request made while logged in)
  • Multi-factor verification (OTP to registered phone or email)
  • Knowledge-based questions (last transaction, registered address)
  • Document-based verification (Aadhaar offline KYC, DigiLocker)

Match the verification standard to the sensitivity of the data involved. Erasure of a marketing list entry needs less than erasure of a financial transaction history.

Stage 3: Discovery and dependency mapping

The single biggest cause of failed DSAR responses: the team forgot a system. The user lives in your CRM, your support helpdesk, your marketing automation tool, your analytics platform, your data warehouse, your backups — and possibly in your processors' systems.

Maintain a dependency map (per RoPA) of every system that may hold Data Principal data. The DSAR workflow walks every system on the list, collects findings, and consolidates.

Stage 4: Response drafting and approval

For complex requests, the response includes:

  • What data we hold (categories and sources)
  • The purpose for each category
  • Whether the request can be fulfilled in full, in part, or refused
  • The reasons for any partial refusal (e.g., statutory retention)
  • The next-step the Data Principal can take if dissatisfied (escalation to Grievance Officer, then DPBI)

Privacy / DPO approval before sending. Legal sign-off for refusals.

Stage 5: Delivery and audit

Deliver via the channel the Data Principal requested (or their registered channel by default). Log the delivery. Close the case with full audit trail. Use Template 10 (DSAR Tracker) for a worked spreadsheet that automates the SLA calculation and RAG status.

The 90-day SLA

Rule 14(3) caps the response at 90 days. This is a ceiling, not a target. Mature programmes target 14-30 days for routine access requests, longer for complex erasure or correction. Track your distribution — if you're consistently above 60 days, your operational design is the problem.

All knowledge articles

Related articles