Data subject access requests under GDPR: search before you export (2026)

A customer writes, "Send me everything you hold about me." Your team opens the main account database, exports the profile, and prepares a reply. The export contains the name, email address, orders and support status. It leaves out the support messages, activity logs, inferred risk score, vendor-held records and the information that explains who receives the data.

A data subject access request (DSAR) is complete when the organisation answers the legal question, not when one application produces a file. The GDPR right of access covers three things: confirmation that personal data are being processed, access to the personal data, and information about how the organisation processes that data. The work is a controlled search-and-disclosure task across the organisation's real data surfaces.

What the right of access contains

Article 15 gives a person the right to obtain confirmation of whether personal data concerning that person are being processed. When the answer is yes, the person receives access to the personal data and supplementary information about the processing. The supplementary information includes purposes, data categories, recipients, storage period or criteria, available rights, the right to complain, the source of data collected elsewhere, and information about automated decision-making and profiling. Transfers to third countries add the appropriate safeguards under Article 46. 1

The EDPB describes those entitlements as three components:

Component	What the response must answer	Evidence for the reviewer
Confirmation	Whether the organisation processes personal data concerning the requester.	The systems and processing activities checked, plus the result.
Personal-data access	Which personal data are being processed, supplied as a copy or another appropriate access method.	The search plan, data collected, exclusions or redactions, and delivery record.
Supplementary information	Why the data are used, which categories and recipients are involved, how long the data are kept, which rights apply, where the data came from, and whether profiling or automated decisions are involved.	The current processing facts, linked notices or records, and any tailored explanation.

The EDPB groups the right of access into these three components. 2

The right exists to help people understand and verify the lawfulness and accuracy of processing. The requester does not have to explain why the request matters. The organisation should therefore assess what data and information fall within Article 15, rather than deciding whether the requester's stated purpose is useful. 3

Article 12 sets the operating clock. The controller must act without undue delay and within one month of receiving the request. The controller may extend the period by up to two further months when the complexity or number of requests makes an extension necessary, but the controller must explain the extension within the first month. Responses are generally free. A reasonable fee or refusal is available for a manifestly unfounded or excessive request, and the controller carries the burden of demonstrating that character. 1

Define the scope before searching

The scope follows the GDPR definition of personal data: information relating to an identified or identifiable natural person. The EDPB's examples extend well beyond the fields that a person typed into an account form. They include communications, purchase history, activity logs, search activity, observed data, classifications, creditworthiness indicators, recommendations, algorithmic results, health assessments and other inferences. Pseudonymised data remains personal data when the organisation can link it to the person. 3

That scope changes the search question. Ask, "Which information can our organisation associate with this person?" Ask, "Which information did our organisation use to make a decision about this person?" Ask, "Which records describe the person's activity, even if the records use a customer number, device identifier or pseudonym?"

A hiring team, for example, may hold a CV, interview notes, a panel assessment, a ranking, training records and an internal recommendation. A customer-support team may hold account fields, ticket text, call recordings, authentication events, fraud flags and a service provider's activity logs. The access analysis concerns the personal data in those materials. The document title or the application's name does not settle the question.

A record can contain personal data about more than one person. An email thread may contain the requester's messages and another person's address. A call recording may contain the requester's voice and an agent's voice. The requester can have access rights in the record while the other person's rights still require a separate review. Information that exclusively concerns someone else falls outside the requester's entitlement; mixed information needs a concrete assessment under Article 15(4). 3

Use a request-to-response decision screen

1. Capture the request and its receipt date

A request does not need a prescribed form or a legal citation. The EDPB says that controllers should provide user-friendly channels, while the requester's use of a different official contact point does not remove the controller's duty to route and handle it. The ICO gives the same operational message in its subject-access guidance: people may make requests verbally or in writing, including through social media, when the request clearly seeks their own personal information. The ICO guidance is UK GDPR guidance, so its UK-specific legal updates require separate local analysis; the recognition and routing practice is broadly useful for a GDPR workflow. 3 4

Record the date and channel through which the request reached the organisation. Route requests from customer service, HR, sales, security or a vendor-management mailbox to the response owner. The owner should acknowledge receipt, state the working deadline, and identify any immediate identity or scope question.

2. Verify identity with the least additional data

Identity verification protects the requester from a disclosure to the wrong person. It also creates a data-collection risk when a team demands a full identity document from every requester.

Start with authentication the organisation already uses. A logged-in customer account, a verified email address, or a one-time code sent to a trusted contact channel may already link the requester to the relevant records. When reasonable doubts remain, request only the information needed to confirm the link. The EDPB says the proportionality assessment should consider the type of data processed, the nature of the request, the context, and the harm that an improper disclosure could cause. The EDPB also says that a copy of an identity document is generally disproportionate for a person who is already authenticated by the controller. 3

Record the identity basis, the reason for any additional check, the data requested from the person, and the date the check was satisfied. A proportionate check should reduce the risk of misdelivery without creating a second, unnecessary identity dossier.

3. Set the scope and use clarification carefully

The default interpretation of an access request is broad: it covers all personal data concerning the requester. The EDPB allows a controller that holds a large quantity of information to ask the requester to specify the processing or information sought. The controller should first give a meaningful overview of the relevant processing contexts so that the person can make an informed choice. Clarification should help the person handle the response; it should not hide an unexpected database or silently turn an all-data request into a profile-only request. If the requester confirms that the request covers all personal data, the controller must provide it in full, subject to applicable limits. 3

A useful scope note names:

the person or account being matched;
the time period, if the requester stated one;
the business activities that may process the person's data;
the processors and platforms that may hold or access the data; and
any specific request for a communication, decision, recording or other record.

Keep the scope note separate from the organisation's decision about what to disclose. Scope describes what the request reaches. Disclosure review decides whether a lawful limit applies to a particular item.

4. Search according to the data, not the org chart

The EDPB says that a controller should search its IT systems and non-IT filing systems using criteria that match the way the organisation structures information. The search may need names, customer numbers, usernames, IP addresses, device identifiers, professional titles, family relationships or other identifiers that the controller holds and that can produce a match. The search extends to relevant processor-held data. 3

A practical search plan should cover the surfaces that can change the answer:

Core records: account, CRM, HR, case-management, billing and identity systems.
Communications: email, chat, call recordings, support tickets, complaints and correspondence repositories.
Observed activity: access logs, transaction history, device events, website or application activity, location records and security footage where the GDPR applies.
Derived and inferred records: risk scores, classifications, eligibility decisions, recommendations, profiling outputs and the inputs used to make a decision about the person.
Documents and manual files: structured paper files, interview notes, investigation folders and other filing systems within the GDPR's scope.
External processing: processors, subprocessors and support channels that store or can retrieve the person's data.

For each surface, record the search owner, identifiers used, date searched, result, and any known retention or deletion event. If a processor performs the search, keep the processor's confirmation and the controller's review of its result. A response owner should be able to explain why a surface was included or excluded without relying on a product team's memory of how the application works.

5. Assemble the data and the explanation together

The response should reflect the data available when the organisation received the request. EDPB guidance says that the copy can include inaccurate or unlawfully processed data as held at that time; a later correction should not erase the evidence that the requester used the access right to discover the problem. Data already deleted under a valid retention rule is no longer available to provide, but short retention periods require retrieval measures that preserve the ability to answer a request received while the data existed. 3

Raw data can require context. A file of event codes, short labels or machine-generated scores may satisfy a literal export while leaving the requester unable to understand what the records mean. The EDPB gives the example of activity logs and marketing data: the underlying records remain within scope, and the controller may need to explain codes and abbreviations in a user-friendly form. 3

Build the response in layers when a large volume would otherwise bury the reader:

an index of processing contexts and data groups;
the supplementary information for those contexts;
the personal-data files or a clearly described copy of the data; and
explanations for codes, scores, identifiers and any redactions.

A layered response still has to supply the covered information. A link to a privacy notice or a self-service export can support delivery, but the organisation remains responsible for providing the Article 15 information and for filling the gaps that the tool cannot cover. The EDPB says the controller should document why the chosen delivery method is appropriate and should use a commonly used electronic form for an electronic request. 3

6. Review other people's rights before delivery

Article 15(4) protects the rights and freedoms of others when the controller provides a copy. The rule calls for a concrete review. The controller should identify the information about another person, assess the actual adverse effect of disclosure, look for a way to reconcile the interests, and redact or withhold the protected part where that resolves the risk. A general concern that an email, recording or investigation file contains another person's information is insufficient by itself. 1 3

The EDPB's sequence is useful for a review record:

Identify the specific rights or freedoms that disclosure would affect.
Assess the likelihood and severity of the effect in this request.
Try to reconcile the competing interests through redaction, masking or another targeted measure.
Provide the remaining personal data and supplementary information.
Record the part withheld, the legal basis, the mitigation considered, and the reason the remaining response is complete.

The same discipline applies to a refusal or fee based on a manifestly unfounded or excessive request. Article 12(5) sets a high threshold and places the demonstration burden on the controller. Workload, organisational inconvenience or a broad request alone does not establish the threshold. EDPB guidance also separates an extension for a genuinely complex request from an excessive-request decision: a large effort by itself does not make the request complex, and a large company's ordinary request volume does not automatically justify an extension. 1 3

7. Deliver securely and close the record

Choose a delivery method that matches the sensitivity of the information. Electronic delivery should use appropriate security measures. A remote portal can work when the requester can download a usable copy and the organisation can supply the information the portal does not contain. The ICO's operational guidance also calls for a reasonable and proportionate search, a clear and accessible response, and secure delivery. 3 4

Before sending, check the one-month deadline, any properly notified extension, the identity basis, the recipient address or portal account, the encryption or access-control step, and the completeness of the supplementary information. Preserve the final response, delivery evidence, search returns, redaction decisions and any follow-up owner.

Shortcuts that produce the wrong answer

Shortcut	What it leaves unresolved	Repair
Export the main application profile	Vendor records, communications, logs, derived data, manual files and other processing contexts.	Search by the person's identifiers across every relevant system, filing system and processor.
Send the privacy notice	General processing information rather than the person's personal-data copy and tailored supplementary information.	Use the notice as one source for the explanation, then supply the person's data and current processing details.
Send a data-portability file	Portability has a different purpose and a narrower data set than the Article 15 access right.	Treat portability and access as separate response paths. The access search includes derived, inferred and other personal data within scope.
Demand a full identity document from every requester	Unnecessary identity data and a burden that can delay a legitimate request.	Use existing authentication first and request only proportionate additional information when reasonable doubts remain.
Refuse because the search is difficult	Article 12 has narrow rules for manifestly unfounded or excessive requests, and the controller must demonstrate the threshold.	Search, document the effort and issue a complete response; use a specific lawful limit only for the affected information.
Redact an entire thread or recording because another person appears in it	The requester's own personal data and the rest of the record.	Assess the concrete rights impact and redact the smallest protected part that resolves it.

The distinction between access and portability matters in system design. A download button can serve one right and fail the other. A controller that stores only a portable export may still lack a reliable route to retrieve decisions, inferred attributes, support communications or records held by a processor.

The reviewer record

Keep one compact record that lets another practitioner reconstruct the response:

Request: requester, channel, exact receipt date, stated scope and deadline.
Identity: authentication already available, extra information requested, reason and outcome.
Scope: processing contexts considered, clarification exchanged, and the final scope.
Search: systems, filing systems, processors, identifiers, owners, search dates and results.
Data: categories returned, current processing information, source, recipients, retention, transfers and profiling details.
Review: third-party information, rights and freedoms considered, exemptions, redactions and the reason for each withheld item.
Delivery: format, security measure, recipient verification, date sent and evidence of delivery.
Follow-up: correction, erasure, complaint, incident or system-design work triggered by the response.

A complete DSAR response gives the person a usable view of the processing and gives the organisation an auditable account of how it searched and disclosed. The practical test is simple: could a reviewer explain what the organisation searched, what it found, what it supplied, and why every omitted item stayed out? If the answer depends on the main application's export button, the search is still unfinished.

References

1
Regulation (EU) 2016/679, Articles 12 and 15
eur-lex.europa.eu
2
EDPB Guidelines 01/2022 on data subject rights - Right of access
edpb.europa.eu
3
EDPB Guidelines 01/2022 - version 2.1
edpb.europa.eu
4
ICO: A guide to subject access
ico.org.uk