Data subject request handling

The data subject request handling requirement means you must run a repeatable, documented process to receive, verify, track, fulfill, and respond to privacy rights requests (access, correction, deletion, and related rights) within defined timelines and with provable controls. To operationalize it quickly, implement an intake-to-closure workflow with identity verification, system search procedures, exception handling, and audit-ready records aligned to ISO/IEC 27701 expectations ¹.

Key takeaways:

• Build one workflow that covers intake, identity verification, triage, fulfillment, and closure, with timeline tracking end to end.
• Tie fulfillment to a maintained “systems of record” map so searches and deletions are complete and repeatable.
• Retain evidence: request log, verification results, decisions, system queries, fulfillment outputs, and communications.

Data subject request handling is one of those privacy requirements that looks simple on paper and fails in execution. The failure mode is predictable: requests arrive through random channels, the business guesses at timelines, teams do one-off searches, and the organization can’t prove what it did or why. ISO/IEC 27701 expects a privacy information management system (PIMS) that can support data subjects’ rights requests with consistent handling and evidence ¹.

This page translates the data subject request handling requirement into an operating model a CCO, privacy lead, or GRC owner can stand up fast. The emphasis is operational: how requests enter your organization, how you confirm the requester is who they claim to be, how you locate data across systems and third parties, how you apply exceptions and partial fulfillment, and what artifacts you must retain for audits and customer disputes.

If you already run a ticketing tool, the fastest path is to formalize it: define request types, add required fields, implement verification steps, assign owners, and create standard response templates. If you don’t, implement a lightweight workflow first, then expand into automation once you have clean process and consistent evidence.

Requirement: data subject request handling requirement (ISO/IEC 27701)

ISO/IEC 27701’s intent is that you can support requests for access, correction, deletion, and related privacy rights through a managed process that produces consistent outcomes and records ¹. Practically, auditors will look for two things:

1. A defined process that is actually used (not a policy sitting on a shelf).
2. Evidence that requests are handled consistently, securely, and within your stated timelines.

Plain-English interpretation

You need a “DSR factory” that reliably does five jobs:

• Receive requests from data subjects (and authorized agents).
• Verify identity (and authority) before disclosing or changing data.
• Locate and act on relevant data across systems and third parties.
• Respond with a clear outcome (fulfilled, partially fulfilled, denied with rationale).
• Prove it later with a clean audit trail.

“Related rights” vary by jurisdiction and contract. ISO 27701 is a framework, so you operationalize broadly: build a workflow that can accommodate multiple rights types and multiple regional rules, then configure timelines and exceptions based on your legal requirements.

Regulatory text

Provided excerpt (framework summary): “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.” ¹
Control intent summary: “Support requests for access, correction, deletion, and related privacy rights.” ¹

What the operator must do: Implement and operate a request-handling workflow with timeline tracking and verification controls, and keep evidence that requests were authenticated, routed correctly, fulfilled across applicable systems, and closed with documented outcomes ¹.

Who it applies to

Entities

• Controllers: You decide purposes/means of processing. You own the “answer” to the data subject and must coordinate across processors and internal systems.
• Processors: You act on behalf of a controller. You must support the controller’s request handling by searching, exporting, correcting, deleting, or restricting processing in systems you operate, and by meeting contractual timelines ¹.

Operational context (where it shows up)

• Customer and consumer support queues (email, web forms, in-app).
• Employee/HR requests (if you process employee personal data).
• Marketing and identity systems (CRM, CDP, email platforms).
• Data warehouses, analytics tools, log systems (where “forgotten” copies often live).
• Third parties that store or process personal data (cloud platforms, support tools, payment providers).

What you actually need to do (step-by-step)

Use this as your build sheet. Keep it simple first, then harden.

1) Define request types and scope

Create a controlled list of request types you will accept and process, aligned to “access, correction, deletion, and related rights” ¹.

• Access (copy of data, categories, purposes)
• Correction/rectification
• Deletion/erasure
• Restriction/objection (where applicable)
• Portability (where applicable)
• “Do not sell/share” or consent withdrawal (where applicable)

Deliverable: DSR taxonomy (a one-page table) plus definitions your intake team can follow.

2) Stand up intake channels and normalize into one queue

Pick controlled intake channels (web form and privacy email are common) and route everything into a single case management queue (ticketing system is fine). Your goal is one log with one case ID per request.

Minimum intake fields:

• Requester name, contact method
• Relationship (customer, end user, employee, agent)
• Request type
• Identifiers to locate records (email, account ID, device ID as applicable)
• Jurisdiction/region (if known)
• Any deadlines you commit to internally

Deliverable: DSR intake form and case queue with required fields.

3) Perform identity verification (and agent authority checks)

Before you disclose, delete, or correct data, verify identity in a way that fits risk:

• If the request comes from an authenticated account, use account login plus challenge questions for sensitive actions.
• If unauthenticated, require reasonable proof (documented in your procedure) and minimize collection of new sensitive data during verification.

If an authorized agent submits the request:

• Verify the agent’s authority (written authorization or power of attorney, depending on your rules).
• Verify the data subject’s identity separately when required.

Deliverable: Identity verification procedure with decision points and escalation triggers.

4) Triage and assign owners with timeline tracking

Assign each request an owner and due date in the system. Track:

• Intake date
• Verification completion date
• Search initiated/completed
• Fulfillment completion
• Response sent
• Closure date

This is the “timeline tracking” auditors expect to see as operational evidence ¹.

Deliverable: SLA clock rules in the ticketing workflow and a DSR status model (New → Verifying → In Search → In Fulfillment → Responded → Closed).

5) Execute a repeatable search across systems (use a system map)

Create and maintain a “where personal data lives” map:

• Systems of record (CRM, product DB)
• Secondary systems (support, marketing, analytics)
• Data stores (warehouse, backups policy notes)
• Third parties and subprocessors

Then create a standard search playbook:

• Search keys per system (email, user ID, phone, cookie ID)
• Export steps for access requests
• Correction steps (and propagation rules)
• Deletion steps (and retention exceptions)

Deliverable: DSR system search matrix (system, owner, data types, search key, action steps, evidence to capture).

6) Apply exceptions and partial fulfillment rules

Not every request gets full execution. You need documented rules and a review step for:

• Conflicting legal retention obligations
• Security and fraud prevention constraints
• Requests that would expose another person’s data
• Inability to verify identity

Keep decisions consistent. Require approval (privacy counsel/CCO/designee) for denials and complex partial fulfillments.

Deliverable: Exception/denial rubric and approval workflow.

7) Respond with standard templates and secure delivery

Create templates for:

• Verification needed
• Extension/clarification needed
• Fulfilled (with what you provided/did)
• Partially fulfilled (what you did, what you didn’t, and why)
• Denied (why, and how to appeal or complain where applicable)

Deliver data securely (download portal, encrypted email, or authenticated account message). Don’t attach sensitive exports to plain email.

Deliverable: Response template library and secure delivery method documented.

8) Close the case, retain evidence, and feed continuous improvement

At closure:

• Confirm actions are completed across systems and third parties (or document any exclusions).
• Record final outcome and approvals.
• Tag root cause issues (missing system mapping, broken deletion job, unclear ownership).

Deliverable: DSR metrics dashboard (counts by type, aging, bottlenecks) and a quarterly review cadence.

Required evidence and artifacts to retain

Auditors and customer disputes are evidence-driven. Retain:

• DSR policy/procedure (roles, steps, timelines, exceptions) ¹
• Request log/case records (unique ID, dates, status history)
• Identity verification evidence (what was checked, by whom, and result)
• System search evidence (queries run, system screenshots/logs, export files generated, deletion confirmations)
• Decision records for denials/partial fulfillment (rationale, approver)
• Communications (inbound request, clarification questions, final response)
• Third-party tasking evidence (processor requests, confirmations, timestamps)
• Training records for staff handling requests
• Change control records when you update workflows or templates after findings

Evidence quality rule: if a request is challenged later, a reviewer should reconstruct exactly what happened without interviewing the original handler.

Common exam/audit questions and hangups

Expect these and prepare answers with artifacts:

• “Show me your end-to-end workflow for access and deletion requests.”
• “How do you verify identity before releasing data?”
• “How do you ensure you searched all relevant systems, including third parties?”
• “Who can approve a denial or partial fulfillment, and what criteria do they use?”
• “Show three recent completed cases and the evidence trail for each.”
• “How do you handle requests received through non-standard channels (sales inbox, support chat)?”
• “How do you prevent accidental deletion of data needed for legal holds or retention obligations?”

Hangup: teams can describe the process but can’t produce consistent case evidence. Fix this by enforcing required fields and attachments in the case tool.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating DSR as email-only.
  Fix: force all requests into one case queue with required metadata and timestamps.

• Mistake: Weak identity verification that risks improper disclosure.
  Fix: define verification levels by risk and require approval for edge cases.

• Mistake: No system map, so searches are incomplete.
  Fix: build the system search matrix and assign system owners responsible for DSR actions.

• Mistake: Deletion without documenting exceptions.
  Fix: add an exception rubric and a required “retention/legal hold check” step.

• Mistake: No third-party coordination.
  Fix: maintain a list of third parties that process personal data and a standard outbound request template plus tracking.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list specific cases. Operationally, the risk concentrates in three areas:

• Unauthorized disclosure if identity verification is weak.
• Incomplete fulfillment if your system map and third-party coordination are immature.
• Audit failure if you can’t produce evidence that the workflow ran as designed ¹.

Practical 30/60/90-day execution plan

Day 0–30: Stand up a minimum viable DSR workflow

• Assign an accountable owner (privacy lead/CCO delegate) and backups.
• Create the DSR taxonomy, intake form, and case queue with required fields.
• Publish the identity verification procedure and denial/exception escalation path.
• Draft response templates and require secure delivery for exports.
• Run tabletop tests on common scenarios (access, deletion, agent request).

Day 31–60: Make it complete and auditable

• Build the system search matrix and assign system owners.
• Add third-party/subprocessor coordination steps (request templates and tracking).
• Implement workflow gates: no fulfillment without verification, no denial without approval.
• Start retaining standardized evidence in every case (attachments, checklists).

Day 61–90: Harden operations and reduce cycle time

• Add metrics (aging, reopened cases, common bottlenecks) and a review cadence.
• Train support, privacy, and engineering system owners; test knowledge with sample cases.
• Run an internal audit: select closed cases and verify evidence completeness.
• Consider tooling consolidation or automation. Daydream can help centralize intake, timeline tracking, and evidence collection so your DSR process stays audit-ready as volume increases.

Frequently Asked Questions

Do we need one process for all privacy rights, or separate workflows?

One workflow with configurable request types is easier to operate and audit. Use the same intake, verification, tracking, and evidence model, then branch into different fulfillment steps per request type.

How strict does identity verification need to be?

Strict enough to prevent disclosure or destructive actions to the wrong person, and consistent enough that handlers don’t improvise. Document verification levels and require escalation for edge cases ¹.

What if we can’t delete data due to retention or legal holds?

Record the exception, limit processing where possible, and respond clearly with what you did and why you could not complete full deletion. Require approval for the exception decision and retain the decision record.

How do we handle requests that come through support chat or a sales rep?

Train frontline teams to route any privacy-rights request into the official intake queue immediately. Treat the message as the original request, preserve it in the case record, then proceed with verification and triage.

What evidence do auditors typically want to see first?

A request log with timestamps, your written procedure, and a small sample of closed cases with identity verification proof and system search/deletion confirmations. If those are clean, deeper testing usually goes faster ¹.

We’re a processor. Do we respond directly to the data subject?

Usually you support the controller and follow contractual instructions. Build the same internal workflow so you can execute searches, exports, corrections, and deletions in your systems and provide timely confirmations back to the controller ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. ISO/IEC 27701 overview