GDPR Data Subject Access Request process: a GRC team implementation guide

GDPR Chapter III grants data subjects eight rights regarding their personal data: right of access (Article 15), rectification (Article 16), erasure (Article 17), restriction (Article 18), data portability (Article 20), objection (Article 21), and rights related to automated decision-making (Article 22).

Organizations must respond to valid requests without undue delay and within one month of receipt. This period may be extended by two additional months for complex or numerous requests, with notification to the data subject within the initial one-month period.

Failure to respond within statutory timelines is one of the most common GDPR complaint triggers. GRC teams must establish workflows that consistently meet deadlines, not only handle requests correctly when time permits.

Establish accessible intake channels: dedicated email address, web form, or customer portal. Privacy notices must inform data subjects how to exercise their rights and identify the contact point.

Identity verification prevents unauthorized disclosure of personal data to third parties. Request sufficient information to confirm the requester's identity without demanding excessive documentation. For existing customers, account authentication may suffice. For non-customers, reasonable identity evidence such as government ID may be appropriate.

Document verification procedures and apply them consistently. Supervisory authorities have criticized organizations that apply inconsistent or excessive verification requirements that effectively prevent data subjects from exercising their rights.

DSAR fulfillment requires coordination across legal, customer support, engineering, and product teams. Define roles clearly: who receives and logs requests, who verifies identity, who extracts data from systems, who reviews responses for third-party data, and who approves final delivery.

Create a DSAR tracking system with request ID, receipt date, deadline, request type, status, assigned owner, and completion date. Manual tracking via email threads fails at scale and creates compliance gaps.

For erasure requests, engineering must identify all systems containing the data subject's personal data, including backups, analytics platforms, and subprocessor systems. Maintain a data map that accelerates system identification during DSAR processing.

• Legal or privacy team: intake, verification, and response approval
• Customer support: initial receipt and customer communication
• Engineering: data extraction, erasure execution, and system queries
• Product: in-app request handling and data export features
• Compliance: tracking, deadline monitoring, and audit trail maintenance

Article 15 access requests require providing the data subject with: confirmation of processing, copy of personal data, processing purposes, categories of data, recipients, retention periods, rights information, and the source of data if not collected from the data subject.

Data exports should be in a commonly used electronic format. Structured exports (JSON, CSV) are preferred over PDF summaries for data portability alignment. Include all personal data across systems, not only data visible in the user-facing product.

Review exported data for third-party personal data before delivery. Redact information about other individuals that may appear in communications, support tickets, or shared documents.

Article 17 erasure requests require deletion of personal data when processing is no longer necessary, consent is withdrawn, or the data subject objects to processing. Exceptions apply for legal obligations, public interest, and legal claims.

Erasure must extend to subprocessors and backup systems within reasonable timelines. Document erasure actions including systems affected, data categories deleted, and confirmation from subprocessors.

Restriction requests (Article 18) require limiting processing to storage only while disputes are resolved. Objection requests (Article 21) require ceasing processing based on legitimate interests unless compelling grounds override the data subject's interests.

Organizations may refuse or charge reasonable fees for manifestly unfounded or excessive requests, but the burden of demonstrating manifest unfoundedness rests on the controller. Document refusal rationale carefully, as supervisory authorities scrutinize refusal patterns.

Exemptions exist for requests that adversely affect the rights of others, require disproportionate effort, or conflict with legal privilege. Apply exemptions narrowly and document the specific basis for each refusal.

Maintain complete audit trails for every DSAR: request receipt, identity verification, internal processing steps, data sources queried, response content, delivery confirmation, and any refusal or extension rationale.

DSAR volume increases with customer base growth and regulatory awareness. Organizations processing thousands of requests annually should invest in automation: self-service data export in customer portals, automated identity verification, and workflow tools with deadline tracking.

Automation must not compromise response quality or compliance. Automated exports should be reviewed for completeness and third-party data before delivery. Human approval should remain in the workflow for erasure requests and complex access requests.

Benchmark DSAR metrics: average response time, requests by type, refusal rate, and extension frequency. Report to management regularly and use trends to identify systemic issues such as incomplete data maps or subprocessors that delay fulfillment.