What the right of access is

The right of access (often called a DSAR or “subject access request”) allows individuals to ask whether an organization processes their personal data and to receive a copy of that data along with key information about the processing.

The goal is transparency and control: people should be able to understand what data you hold, why you hold it, how you use it, and who you share it with.

What you must provide (and what you can withhold)

A strong access response typically includes two parts: (1) a “processing summary” (the contextual information), and (2) a copy of the person’s personal data (often exported from systems).

Typical response components

A step-by-step DSAR workflow

Treat access requests like a ticketed process with a clear owner, a timeline, and a secure delivery channel.

Operational workflow (recommended)

1. Intake and log: capture requester details, scope, date received, and request channel.
2. Acknowledge receipt: confirm you received the request and explain next steps and identity check.
3. Verify identity: use proportionate methods; document verification outcome.
4. Clarify scope (if needed): narrow broad requests to reduce time and risk (without blocking rights).
5. System search and export: pull data from defined systems and relevant repositories.
6. Review and redact: remove third-party data and security-sensitive details as required.
7. Quality check: verify completeness, consistency, and that the data matches the requester.
8. Secure delivery: encrypted file transfer or secure portal; avoid plain email attachments.
9. Close and retain evidence: store request log, response copy, and rationale for redactions.

Identity verification and security

Identity verification is non-negotiable. A DSAR response can contain highly sensitive information. Verification should be proportionate to risk: more rigorous for sensitive data, less for low-risk accounts.

Common verification approaches (proportionate)

• Account-based verification: respond via the logged-in account or a secure portal.
• Out-of-band confirmation: confirm using a previously verified email/phone on file.
• Document checks (careful): only when necessary; avoid collecting excess ID data.
• Knowledge-based checks: confirm order IDs, last invoice amount, or similar (avoid weak secrets).

How to find data across systems

The largest DSAR risk is missing data (incomplete response) or disclosing the wrong person’s data. Build a repeatable search playbook.

Start with your “system list”

• Customer systems: CRM, support desk, email marketing, payment/billing, product database
• Web and analytics: logs, analytics tools (as applicable), cookie consents
• Internal repositories: shared drives, spreadsheets, exported lists
• Communication tools: support inboxes, ticket notes, recorded calls (if applicable)
• HR systems (for employee requests): HRIS, payroll, time tracking, recruiting

Practical controls to reduce DSAR burden

• Minimize exports: limit CSV downloads and uncontrolled list sharing.
• Standardize identifiers: keep consistent customer IDs across tools.
• Retention enforcement: delete old data so you don’t have to search it forever.
• Centralized logging: keep security logs in controlled systems with defined retention.

Redaction and third-party data

Access rights are not a license to disclose other people’s data. If your records contain third-party data (e.g., support tickets mentioning another customer, internal notes about an employee), you may need to redact.

Typical redaction cases

• Third-party identifiers: names, emails, phone numbers of other individuals.
• Security-sensitive details: credentials, tokens, detailed detection logic, internal security notes.
• Legal privilege: communications protected under applicable legal privilege (context-dependent).
• Trade secrets/confidential business info: where disclosure would cause harm (handle carefully).

Response structure (practical template)

Use a consistent structure so your team can respond quickly and defensibly.

Suggested response structure

• 1) Verification confirmation: “We verified your identity on 2026 using [method].”
• 2) Processing summary: purposes, categories, recipients, retention, rights.
• 3) Data copy: attached/export pack, format description, date range covered.
• 4) Redactions/exclusions: brief explanation of why some data was withheld (if applicable).
• 5) Next steps: how to request correction/deletion, how to escalate concerns.

Right of access checklist (copy/paste)

Use this checklist to handle access requests correctly and consistently.

• We logged the request (date, channel, requester details, scope).
• We acknowledged receipt and explained next steps and timelines.
• We verified identity before searching and disclosing any data.
• We clarified scope if needed (without unreasonably delaying the request).
• We searched all relevant systems using a defined system list and identifiers.
• We reviewed data for accuracy and ensured it belongs to the requester.
• We redacted third-party data and security-sensitive details where necessary.
• We delivered the response securely and retained evidence of completion.

Sources & further reading

Use primary legal texts and regulator guidance when designing and operating DSAR processes.

1. GDPR (Regulation (EU) 2016/679) – EUR-Lex
2. European Data Protection Board (EDPB) – Guidelines & resources
3. ICO – Right of access guidance (practical)
4. Swiss Federal Act on Data Protection (FADP) – Fedlex
5. NIST Privacy Framework (program design)

Last updated: February 22, 2026 • Version: 1.0