DSP-11 — Personal Data Access, Reversal, Rectification and Deletion

Every framework that asks this

Answer DSP-11 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.

Full provenance and NIST 800-53 mappings: the framework crosswalk.

What the reviewer is really checking

The reviewer is establishing whether you have a real data map, not a slogan. They want evidence that you can name the categories of data you process (and specifically whether any of it is regulated — PII, PHI, cardholder, or the buyer's own confidential content), where each category physically lives, who can reach it, and on what schedule it is retained and destroyed. Behind the questionnaire sits a concrete worry: if this vendor cannot describe its own data lifecycle, it cannot honor a deletion request, prove residency to our regulators, or contain a breach. They are also checking for lifecycle coverage — classification at intake, protection in use and at rest, minimization, retention limits, and verifiable disposal — because a gap at any stage is where data leaks or lingers. Reviewers cross-check your data-flow claims against your subprocessor list and your encryption answers; inconsistency between those reads as a vendor that answered from a template rather than from its own systems. For regulated buyers, DSAR/data-subject-request handling and a stated residency model are gating, not optional. The unstated question under every DSP item is: 'When we ask you to delete our data, can you actually prove you did, everywhere it lived?'

What a truthful, defensible answer contains

A defensible answer describes your own data lifecycle in specifics you could be audited against. It names the data classification scheme you actually use (the tier labels and what triggers each), and ties handling rules — encryption, access, logging — to those tiers. It states retention periods per data category with the disposal method and who owns the schedule, rather than 'as long as necessary.' It identifies data residency: the regions or cloud locations where each category is stored and processed, and whether the buyer can constrain that. It describes how a data-subject or deletion request is received, fulfilled across primary stores, backups, and subprocessors, and evidenced back to the requester with a timeframe. It covers the full arc — classification and minimization at collection, protection in use and at rest, and verified destruction — and points to the policy and system that enforces each stage. Crucially it answers only for the data you genuinely process: if you do not hold a category, say so plainly rather than claiming a control you never exercise. A strong answer reads like it was written from your data inventory, because it was — every claim maps to a store, a schedule, or a documented procedure a reviewer could ask to see.

Make it traceable

Make each DSP claim point at an artifact, not a paragraph. A retention claim should reference the dated retention schedule and the deletion job or ticket that proves the schedule runs. A residency claim should reference the region configuration or architecture record, not just a sentence. A DSAR claim should reference the documented procedure plus a redacted example of a completed request with its timestamp. This is the Promise–Proof discipline: the outbound sentence in the questionnaire and the inbound evidence are the same governed fact, so a reviewer who clicks through lands on the classification policy, data-flow diagram, or disposal log that substantiates the words. When the underlying source changes — a new region, a shortened retention window — the answer should update from that source rather than drifting into staleness. If a claim cannot be traced to a store, schedule, or procedure, it is a promise you cannot yet prove and should be softened or omitted.

Answer patterns that hold up

• State classification tiers you use, then bind handling rules (encryption, access, logging) to each tier — without asserting a specific level you do not enforce.
• Give retention as a per-category schedule (category → period → disposal method → owner), pointing to the dated schedule rather than 'as long as necessary.'
• Describe residency as named regions/locations per data category and whether the buyer can constrain them, tied to your architecture record.
• Describe DSAR/deletion handling as a procedure: intake channel, fulfillment across primary stores + backups + subprocessors, and evidence returned within a stated timeframe.
• Where you do not process a data category, say so explicitly rather than claiming a control over data you never hold.

Evidence that backs the answer

Red flags reviewers catch

• 'We take data privacy seriously' with no classification scheme, schedule, or system named.
• Retention stated as 'as long as necessary' or 'per legal requirements' with no actual period or owner.
• A deletion claim with no description of how deletion reaches backups and subprocessors.
• Residency answered as 'data is stored securely in the cloud' with no region or location.
• Data-flow answers that contradict the subprocessor list or the encryption answers elsewhere in the same questionnaire.

Sources

• CSA Cloud Controls Matrix v4 (DSP domain)
• NIST SP 800-53 Rev. 5 (PT — PII Processing and Transparency family)
• ISO/IEC 27001:2022 — A.5.12 Classification of information, A.5.14 Information transfer, A.8.10 Information deletion, A.8.11 Data masking
• AICPA SOC 2 Trust Services Criteria (Confidentiality, Privacy)

Other Data Security and Privacy Lifecycle Management controls