Article 15: Right of access by the data subject

Article 15 (“Right of access by the data subject”) is the backbone of most data subject access request (DSAR) programs because it forces you to prove you can find and produce personal data on demand, across your applications, data stores, and third parties. The requirement is straightforward in concept: confirm whether you process the person’s data, provide access to it, and provide required information about the processing (Regulation (EU) 2016/679, Article 15). The operational reality is harder: identity proofing, scope decisions, exemptions and redactions, and coordinated searches across fragmented systems.

For a CCO or GRC lead, the fastest path is to treat Article 15 as a measurable operating capability, not a policy statement. You need (1) role clarity (controller vs. processor) for each product/workflow, (2) a documented procedure with named owners and triggers, and (3) recurring evidence that the procedure works under real conditions. If you manage third-party risk, fold processors and other third parties into the workflow early, because access responses often fail at the “we didn’t know where the data was” step.

Regulatory text

Excerpt (provided): “The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data and the following information:” (Regulation (EU) 2016/679, Article 15)

Operator interpretation (what you must be able to do):

1. Confirm processing status. You must be able to answer “Do we process personal data about you?” for the requester (Regulation (EU) 2016/679, Article 15).
2. Provide access to the personal data. If you do process it, you must provide the requester access to the personal data you hold about them (Regulation (EU) 2016/679, Article 15).
3. Provide the required “following information.” Article 15(1) continues beyond the excerpt and lists specific information elements. Your procedure should explicitly map to those elements using the full text (Regulation (EU) 2016/679; GDPR Official Journal Text).

Practical point: treat Article 15 as a response “package” consisting of (a) the data itself and (b) a standardized explanation section that you can generate consistently from your records of processing and privacy notices.

Plain-English requirement (for operators)

When a person asks for access, you must: verify who they are, check whether you process their personal data, and if so, provide a copy of that data plus clear information about how and why you process it (Regulation (EU) 2016/679, Article 15). You also need a defensible record of what you did to answer the request.

Who it applies to

In-scope entities

• Controllers responding to individuals whose personal data they process (Regulation (EU) 2016/679, Article 15).
• Processors are not the direct “responder” under Article 15, but you still need operational readiness because controllers will rely on you to search and export data tied to the requester.

In-scope operational contexts

• Customer and user platforms (account, billing, support, telemetry tied to an individual).
• Employee/contractor data systems (HRIS, IAM, recruiting).
• Marketing and analytics stacks (CRM, email platforms, cookie/identifier-linked profiles).
• Security logs and audit trails where entries can be linked to an identifiable person.
• Third parties processing on your behalf (processors) or jointly shaping the means/purposes of processing, where you must coordinate retrieval and explanations.

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

1) Decide and document your role and scope

• Create a role-and-scope register for Article 15: for each product/workflow, record whether you act as controller or processor, what data categories exist, and which systems store them.
• Tie every system in scope to an accountable owner (system owner + privacy lead + legal approver).

This directly addresses a common risk factor: unclear controller/processor role decisions and scope gaps (Regulation (EU) 2016/679, Article 15).

2) Stand up a single intake path with clear triggers

• Accept requests through a dedicated channel (web form, email alias, ticket type).
• Define what counts as an access request even if the requester does not cite “Article 15” (for example: “send me everything you have on me”).
• Route all requests into a case management workflow (GRC tool, ticketing system, or DSAR platform).

3) Verify identity (and document the method)

• Establish identity verification rules by risk level:
  • Low-risk accounts: authenticated portal access may be sufficient.
  • Higher-risk: request additional proof (without collecting excessive new data).
• Document: what you checked, who approved, and outcomes.

Operational hangup: weak identity verification creates unauthorized disclosure risk. Over-collection creates minimization problems. Your SOP should specify the minimum acceptable proof types per channel.

4) Triage and scope the request

For each request, record:

• Request type: access (Article 15) vs other rights.
• Accounts/identifiers to search (email(s), phone, user ID, device ID where appropriate).
• Any known edge cases: shared inboxes, delegated admin accounts, family accounts, enterprise tenant users.

5) Execute a repeatable “systems search” playbook

Build a systems checklist that your case owner runs every time:

• Primary systems: production app DB, CRM, billing, support, email system.
• Derived data: analytics exports, data warehouse, data lake, feature stores.
• Unstructured content: support attachments, call recordings, free-text notes.
• Security/ops logs: access logs, audit trails that are attributable to the person.
• Backups: decide your position and document it; do not improvise during a request.

For each system, define:

• Search method (query, export, admin UI, vendor assistance).
• Output format (CSV, JSON, PDF).
• Owner and expected turnaround.
• Known limitations (retention windows, deletion schedules, pseudonymization).

6) Coordinate third parties (processors) and internal shared services

• Maintain a list of third parties that may hold personal data for your processing purposes (support tools, marketing platforms, hosting providers, payment processors).
• For each, predefine:
  • How to submit a retrieval request (portal, ticket, DPA contact).
  • Expected response content (export, confirmation, metadata).
  • Evidence you will retain (ticket, export receipt).

If you use Daydream to track third-party inventory and contract obligations, link each third party to your Article 15 workflow so retrieval requests are routed with owners and SLAs, and so evidence is stored with the DSAR case.

7) Compile the response package and apply controls

Before sending:

• Remove data that is not the requester’s personal data when it would disclose information about others (document redaction rationale).
• Validate completeness against your system checklist.
• Add the required “processing information” section aligned to Article 15(1) using your documented processing records (Regulation (EU) 2016/679, Article 15; GDPR Official Journal Text).

8) Approvals and delivery

• Require at least one privacy/legal review for edge cases (mixed data, litigation hold, suspected fraud).
• Deliver securely (authenticated portal download preferred; encrypted email if necessary).
• Record delivery method and confirmation.

9) Close out with a defensible audit trail

Every case should end with a standardized closure record:

• Scope searched, systems queried, third parties contacted.
• Data returned (file list + hashes if your security team supports it).
• Exceptions and rationale.
• Remediation items (missing system connector, data quality issues).

Required evidence and artifacts to retain

Maintain an “evidence packet” per request:

• Intake record (date/time, channel, request text).
• Identity verification record and outcome.
• System-by-system search checklist with timestamps and owners.
• Copies of exports produced (or a secure reference to where stored).
• Redaction/exception decision record with approver.
• Third-party correspondence and exports.
• Final response package and delivery confirmation.
• Post-mortem notes and remediation tasks.

Program-level artifacts (exam-friendly):

• Article 15 operating procedure (SOP) with owners, triggers, approvals.
• Role-and-scope register (controller/processor decisions, systems, data categories).
• Training record for responders and system owners.
• Metrics you can defend qualitatively: backlog status, top failure points, remediation cadence.

Common exam/audit questions and hangups

• “Show me your last few access requests end-to-end.” Expect a sample-based walk-through of evidence packets.
• “How do you know you searched all systems?” Auditors look for a maintained inventory mapped to the checklist.
• “How do you handle data held by processors?” They will test whether your third-party workflow is real (contacts, templates, evidence).
• “Who approves exceptions and redactions?” Lack of named approvers is a frequent gap.
• “How do you ensure responses are consistent with what you tell people publicly?” Your response narrative should align to your privacy notice and processing records (Regulation (EU) 2016/679; GDPR Official Journal Text).

Frequent implementation mistakes (and fixes)

1. Policy-only compliance. Fix: publish an SOP and run table-top tests with real systems and exports.
2. No role clarity. Fix: maintain the controller/processor role-and-scope register per product and third party.
3. Forgetting derived/unstructured data. Fix: add data warehouse, analytics, and support artifacts to the checklist.
4. Ad hoc third-party outreach. Fix: pre-map processors, retrieval steps, and points of contact in Daydream or your TPRM system.
5. Weak evidence retention. Fix: standardize the evidence packet and require it for closure.

Enforcement context and risk implications

No specific public enforcement cases were provided in the source catalog for this page. Treat the risk as practical and exam-driven: Article 15 failures often show up as incomplete responses, inability to prove searches occurred, and inconsistent explanations of processing (Regulation (EU) 2016/679, Article 15).

Practical execution plan (30/60/90-day)

First 30 days (stabilize execution)

• Publish the Article 15 SOP with named owners and an escalation path.
• Stand up a single intake channel and case logging workflow.
• Build the initial systems search checklist for your most important systems.
• Create response templates: “confirmation/no data found,” “data found,” and “need more ID.”

Days 31–60 (expand coverage and defensibility)

• Complete the role-and-scope register across products and key workflows.
• Map third parties that store/process personal data, and define retrieval procedures per third party.
• Run a table-top exercise: simulate a request and execute exports across all mapped systems.
• Implement consistent evidence packet storage with access controls.

Days 61–90 (operational hardening)

• Add coverage for derived and unstructured sources (warehouse, logs, attachments).
• Train system owners and customer support on recognizing and routing access requests.
• Add quality checks: completeness review against checklist, standardized exception approvals.
• Track recurring issues and open remediation items (missing data mapping, broken exports, unclear ownership).

Daydream fit: use it to keep the role-and-scope register, third-party inventory, and evidence packets tied together so you can answer “what did we search, who owns it, and what did we send” without rebuilding the story during an audit.

Frequently Asked Questions

Do we need to respond if we don’t have any data about the requester?

You still need to provide confirmation as to whether personal data is being processed (Regulation (EU) 2016/679, Article 15). Your SOP should include a “no data found” response path with documented searches performed.

What’s the fastest way to avoid missing systems during an access request?

Maintain a living system inventory mapped to your Article 15 search checklist, and require system-owner signoff when systems are added or decommissioned. The checklist, not memory, should drive execution.

How do processors support Article 15 if the controller owns the response?

Build a processor retrieval workflow that produces exports and search attestations on request, and make it contract-operational (named contacts, ticketing path, evidence). Controllers will test you on turnaround and completeness during diligence.

Should we include security logs and audit trails in the access response?

If logs contain personal data concerning the requester and are linkable to them, they can fall into scope for access. Decide your position per log type, document it, and make it consistent with your internal records of processing (Regulation (EU) 2016/679).

Can we standardize the “following information” portion of the response?

Yes. Build a response template fed by your processing records and privacy disclosures, then review it periodically for accuracy (Regulation (EU) 2016/679; GDPR Official Journal Text).

How do we keep DSAR evidence without exposing the exported data internally?

Store evidence packets in a restricted repository with role-based access, and separate “proof of completion” (checklist, timestamps, approvals) from the raw export where appropriate. Document who can access exports and why.