Article 15: Right of access by the data subject

To meet the article 15: right of access by the data subject requirement, you must run a defensible DSAR access process that (1) confirms whether you process the requester’s personal data and (2) provides access to that personal data (and required context) within a controlled, repeatable workflow. Operationalize it with clear ownership, verified identity, system scoping, secure delivery, and audit-ready evidence.

Key takeaways:

• Article 15 requires confirmation + access to personal data when you are the controller. (Regulation (EU) 2016/679, Article 15)
• The operational risk is missing data across systems or mishandling identity, not missing a policy statement. (Regulation (EU) 2016/679, Article 15)
• You need a role-and-scope register, a DSAR access SOP, and evidence packets that prove each request was handled consistently. (Regulation (EU) 2016/679, Article 15)

Article 15 is the “show me what you have” right. A data subject can ask whether you process their personal data and, if you do, obtain access to that data along with the contextual information Article 15 enumerates. The compliance trap is treating this as a privacy inbox task rather than an end-to-end operational capability: intake, identity, scoping, retrieval, review/redaction, secure disclosure, and closure with records.

As a Compliance Officer, CCO, or GRC lead, your job is to make the right executable across the business. That means mapping where personal data lives (including third parties), deciding who owns each step, setting decision points for exemptions and conflicts (for example, where disclosure could affect others), and retaining a clean audit trail. If you operate multiple products, regions, or shared platforms, you also need a repeatable way to determine whether you are acting as controller or processor per activity, because role drives how you respond and how you coordinate with customers.

This page focuses on requirement-level execution guidance you can implement quickly and defend later. Primary source: Regulation (EU) 2016/679, Article 15. (Regulation (EU) 2016/679, Article 15)

Regulatory text

Excerpt (primary text): “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 meaning (what you must do):

1. Be able to answer “Do we process data about this person?” based on a real search across relevant systems, not guesswork. (Regulation (EU) 2016/679, Article 15)
2. If yes, provide access to the personal data in a secure, intelligible form, plus the required contextual information described in Article 15. (Regulation (EU) 2016/679, Article 15)
3. Run it as a controlled process with defined roles, decision points, and records, so you can show consistent handling if challenged. (Regulation (EU) 2016/679, Article 15)

Citation: Regulation (EU) 2016/679, Article 15; full regulation text: Regulation (EU) 2016/679. (Regulation (EU) 2016/679, Article 15) (Regulation (EU) 2016/679)

Plain-English interpretation (requirement-level)

You must provide a data subject with:

• Confirmation whether you process their personal data; and
• Access to the personal data you hold about them (if you process it), plus supporting context Article 15 calls for. (Regulation (EU) 2016/679, Article 15)

Treat Article 15 as an operational capability with two outputs:

• A decision outcome (we do / do not process personal data about you), supported by documented search scope; and
• A disclosure package, supported by documented retrieval and review steps. (Regulation (EU) 2016/679, Article 15)

Who it applies to (entity and operational context)

Applies to: organizations acting as a controller for in-scope personal data. (Regulation (EU) 2016/679, Article 15)

Operational contexts where Article 15 becomes urgent:

• Customer account platforms (identity, contact, billing, usage data)
• HR systems (candidates, employees, contractors)
• Marketing stacks (CRM, email platforms, ad platforms)
• Support tooling (ticketing, call recordings, chat transcripts)
• Security and fraud tooling (logs tied to individuals)
• Third parties processing on your behalf (cloud services, analytics, support outsourcers)

Controller vs. processor reality check:
You need an explicit role decision per processing activity; otherwise teams respond inconsistently, miss downstream systems, or over-disclose data they should route through a controller customer. A role-and-scope register prevents that ambiguity. (Regulation (EU) 2016/679, Article 15)

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

Step 1: Define ownership and an operating procedure (SOP)

Create a requirement-specific SOP with: named owner, backup owner, intake channels, identity verification steps, scoping rules, review/redaction rules, secure delivery method, and closure steps. Make it executable by non-lawyers. (Regulation (EU) 2016/679, Article 15)

Practical control: “Define a requirement-specific operating procedure with named owners, trigger events, and required approvals.” (Regulation (EU) 2016/679, Article 15)

Step 2: Build a role-and-scope register for Article 15

Create and maintain a register that answers, for each product/process:

• Are we controller or processor for this activity?
• What data categories are in scope?
• What systems store or generate the data?
• Which third parties hold it, and what is the retrieval path?
• Who is the system owner and retrieval SLA expectation?

Practical control: “Maintain a GDPR role-and-scope register for this requirement, including controller/processor role, data categories, and affected systems.” (Regulation (EU) 2016/679, Article 15)

Step 3: Stand up DSAR intake with identity verification and logging

Minimum operational expectations:

• Single front door (web form, email alias, ticket type) that routes into a tracked workflow.
• Identity verification proportionate to the risk: authenticate inside an account when possible; otherwise request reasonable proof and record the decision.
• Request logging: request date, requester identifiers, jurisdiction assumptions, product(s), and case owner.

Avoid the common failure mode: responding to the email without creating a case record.

Step 4: Scope the search (systems + third parties)

Use the role-and-scope register to generate a case-specific checklist of systems to search. Record:

• Systems searched (and version/tenant where relevant)
• Search selectors used (email, user ID, phone, device ID, ticket ID)
• Date range applied (and why)
• Third-party retrieval requests issued (if any)

Operational hangup: logs and analytics often contain personal data linked to identifiers. Your SOP should state when those sources are included and how you extract relevant slices.

Step 5: Collect and normalize the data into a disclosure package

Create a standard “access export” format for repeatability:

• Account/profile data
• Transaction/billing records
• Support interactions
• Preferences/consents
• Device/session or security events (where tied to the person)
• Notes on any excluded data and why (document rationale, even if brief)

Keep raw exports immutable; do transformations in a working copy.

Step 6: Review, redact, and resolve conflicts

Before disclosure, run a review to avoid:

• Disclosing other individuals’ personal data (shared inbox threads, group tickets, family accounts)
• Disclosing secrets you are not required to disclose (internal-only risk rules or security-sensitive logic)
• Mixing controller vs. processor responsibilities (for processor contexts, coordinate with the controller customer)

Your SOP should define who can approve exceptions and what gets escalated to counsel.

Step 7: Deliver securely and record completion

Deliver through a secure channel appropriate to the sensitivity (authenticated portal download, encrypted transfer, or other controlled mechanism). Record: delivery method, date, and what was delivered (file hash or export ID helps).

Step 8: Retain an “evidence packet” per request

Practical control: “Retain auditable evidence packets (decision record, control outputs, exceptions, and remediation) on a recurring cadence.” (Regulation (EU) 2016/679, Article 15)

Required evidence and artifacts to retain

Maintain these artifacts in a single case file (ticket + attachments) and in program-level documentation.

Per-request evidence packet (case-level)

• Intake record and requester identifiers
• Identity verification record (what you checked; pass/fail; who approved)
• Scope checklist generated from the role-and-scope register
• System query evidence (screenshots, export IDs, query logs, or admin attestations)
• Third-party outreach and responses (where applicable)
• Disclosure package (final) and delivery record
• Exceptions/denials and rationale (if any), with approver
• Post-mortem notes for misses, plus remediation tasks

Program-level artifacts (control-level)

• Article 15 SOP with roles and escalation paths
• Role-and-scope register (systems, data categories, controller/processor)
• Training records for staff handling DSARs
• Template communications (receipt, identity follow-up, completion)
• Metrics dashboard (qualitative is fine; avoid invented stats)

Common exam/audit questions and hangups

Auditors and regulators usually test execution, not policy language. Expect:

• “Show me three recent access requests and the full evidence trail.”
• “How do you ensure you searched all relevant systems, including third parties?”
• “Who decides whether you are controller vs. processor for a given request?”
• “How do you prevent disclosing someone else’s data in a shared account or ticket thread?”
• “How do you handle requests across multiple products or brands?”

Hangup: teams can’t explain their scoping logic. Fix it with the role-and-scope register and a case checklist tied to it. (Regulation (EU) 2016/679, Article 15)

Frequent implementation mistakes (and how to avoid them)

1. Policy without workflow. Fix: publish an SOP with owners, steps, and required approvals. (Regulation (EU) 2016/679, Article 15)
2. No system inventory for DSAR. Fix: maintain the Article 15 role-and-scope register and review it on a defined cadence. (Regulation (EU) 2016/679, Article 15)
3. Identity verification is ad hoc. Fix: define acceptable verification methods by channel (logged-in vs. email) and require documentation.
4. Overlooking third parties. Fix: map where each third party stores personal data and how you retrieve exports quickly.
5. Inconsistent redaction. Fix: implement a second-person review for high-risk data sets (support transcripts, attachments, free-text notes).
6. No defensible record of what you searched. Fix: require scope evidence (query logs, export IDs, or system owner attestations) in every case.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this section is limited to operational risk grounded in the requirement text. (Regulation (EU) 2016/679, Article 15)

Primary risks tied to Article 15 execution:

• Regulatory escalation when you cannot prove you searched all relevant systems or you respond inconsistently. (Regulation (EU) 2016/679, Article 15)
• Security risk if you disclose personal data to the wrong person due to weak identity checks.
• Contract risk in B2B: customers often flow down DSAR support obligations to processors; weak coordination breaks trust and can trigger contractual remedies.

Practical 30/60/90-day execution plan

First 30 days (stabilize execution)

• Publish the Article 15 SOP with named owners and an escalation path. (Regulation (EU) 2016/679, Article 15)
• Stand up a single intake channel and ticket workflow with mandatory fields (identity method, products, systems searched).
• Start the role-and-scope register with your highest-volume system(s): CRM, support desk, core product DB, marketing platform. (Regulation (EU) 2016/679, Article 15)
• Define a standard disclosure package format and secure delivery method.

By 60 days (expand coverage, prove repeatability)

• Extend the role-and-scope register to remaining systems and key third parties. (Regulation (EU) 2016/679, Article 15)
• Implement retrieval runbooks per system (who exports, how, typical turnaround).
• Add review/redaction rules for free-text fields and attachments.
• Begin retaining evidence packets consistently and run an internal “mock audit” on recent cases. (Regulation (EU) 2016/679, Article 15)

By 90 days (operational maturity)

• Add QA checks: sampling of closed cases for completeness and correctness.
• Integrate DSAR scoping with your data map/ROPA work so system changes trigger register updates.
• Formalize third-party DSAR support: contract points, contacts, and retrieval steps.
• If you need tooling, Daydream can help centralize the role-and-scope register, SOP tasks, and evidence packets so each access request produces a consistent, audit-ready record without chasing screenshots across teams.

Frequently Asked Questions

Does Article 15 require us to confirm whether we process personal data about the requester?

Yes. The excerpt explicitly includes the right to obtain “confirmation as to whether or not” personal data is being processed. (Regulation (EU) 2016/679, Article 15)

Are we only required to provide data, or also explanatory context?

Article 15’s excerpt specifies access to the personal data and “the following information,” which means the response package must include required contextual elements, not just raw exports. (Regulation (EU) 2016/679, Article 15)

What if we can’t find the person in our systems?

You still need a defensible “not processed / not found” outcome supported by documented search scope (systems checked and selectors used). Keep that evidence in the case file.

How should we handle data held by third parties?

Treat third parties as part of your scope. Your register should identify which third parties hold relevant personal data and the retrieval path so you can include those sources in a consistent search.

What’s the minimum evidence auditors expect for an access request?

A complete case file: intake, identity verification, scoping, retrieval outputs, review/redaction decisions, delivery record, and any exceptions. If any step is missing, the case becomes hard to defend.

We’re sometimes a processor for enterprise customers. Who answers the access request?

Role matters. Where you act as a processor, align the workflow to coordinate with the controller customer rather than responding in a way that conflicts with their instructions. Track the role decision in the case record.