Wiki · Concept · Last reviewed June 25, 2026

Data Subject Access Requests

A data subject access request is the practical use of the GDPR right of access: a person asks whether an organization processes personal data about them, receives access to that data, receives a copy, and receives key information about the processing.

Category: Privacy governance Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: GDPR, DSAR, right of access, privacy, AI governance

Definition

A data subject access request, often called a DSAR or subject access request, is a request by an individual to exercise the right of access under Article 15 of the General Data Protection Regulation. The right has three linked parts: confirmation of whether personal data concerning the person is processed, access to that data and a copy of it, and specified information about the processing.

The right is not an AI-transparency right in the broad sense, and it is not civil discovery by another name. It does not require an organization to reveal trade secrets, full source code, all model weights, or every internal deliberation. It is narrower and more durable: the person can ask for their personal data, the purposes of processing, categories of data, recipients, retention information, rights, complaint routes, source information where the data did not come from them, safeguards for third-country transfers, and information about certain automated decision-making.

For AI systems, the access request is one of the few tools by which a watched person can force the institution to search its own traces: prompts, support records, profile attributes, inferred scores, embeddings tied to an account, human-review notes, moderation labels, or decision records, depending on what qualifies as personal data in context.

Snapshot

Scope

Article 15 covers confirmation of processing, access to personal data, and supplementary information. It also gives a right to information about safeguards when personal data is transferred to a third country or international organization, and a right to a copy of the personal data undergoing processing, subject to the rights and freedoms of others.

Article 12 supplies procedural discipline. Controllers must provide information on action taken without undue delay and in any event within one month of receiving the request. That period can be extended by two further months where necessary, taking account of complexity and number of requests, but the controller must inform the person of the extension and reasons within the first month.

The right applies to personal data, not every document that mentions a person and not every artifact produced by an AI system. The hard cases are often mixed records: a classifier label about a worker, a fraud score about a customer, a chatbot transcript involving several people, a moderation note that reveals staff judgment, an access log showing staff or system consultation, or an embedding that can single out an account.

The right also covers information about recipients, retention, data source where the data did not come from the person, and safeguards for third-country transfers. In AI services, that means the response may need to identify model providers, inference hosts, human-review vendors, analytics processors, support platforms, or recipient categories where the actual recipients cannot be identified.

Boundary Tests

Not portability. A DSAR may require a copy of personal data, but the Right to Data Portability has separate Article 20 triggers, format duties, and transfer logic.

Not a model audit. The right of access can reach personal data used in or produced by an AI system, but it does not automatically require full source code, model weights, training corpora, prompts from other users, or an end-to-end safety audit.

Not only raw fields. CJEU case law treats personal data broadly enough to include assessments relating to an identifiable person, and Article 15(3) may require extracts or documents where context is essential for an intelligible copy. A controller should not reduce a DSAR to a list of database columns if labels, scores, review notes, or consultation records are the real processing evidence.

Not unrestricted disclosure. Article 15(4) and related national rules still require balancing where access would adversely affect other people, trade secrets, security, or privileged material. The answer should be targeted redaction or explanation where possible, not a blanket refusal.

Not a private extraction tool. A coerced or enforced request can turn a personal right into surveillance by another party. DSAR workflows should be designed to support the data subject's agency, not an employer, lender, insurer, landlord, or abusive actor demanding a copy of someone else's life record.

Current Context

As of June 25, 2026, the EU right of access remains anchored in GDPR Articles 12 and 15, with EDPB Guidelines 01/2022 as the main EU-level interpretive guidance. The EDPB guidelines emphasize that the right of access helps people know and verify the lawfulness of processing, and that controllers should make the first response complete enough for the person to understand the processing rather than forcing repeated requests.

The Court of Justice has made several access obligations more concrete. In Österreichische Post, Case C-154/21, the Court said a controller must provide the actual identity of data recipients on request where data has been or will be disclosed, unless recipients cannot be identified or the request is manifestly unfounded or excessive. In Pankki S, Case C-579/21, the Court treated dates and purposes of consultation operations as access-right information, while saying staff identities are not automatically disclosed when those employees acted under the controller's authority and instructions.

Court of Justice case law has made the "copy" obligation more concrete. In Österreichische Datenschutzbehörde and CRIF, Case C-487/21, the Court held that Article 15(3) concerns a faithful and intelligible reproduction of the personal data undergoing processing. Copies of document extracts, whole documents, or database extracts may be needed where essential for the person to understand and exercise GDPR rights, while the rights and freedoms of others still have to be considered.

Automated decision-making remains a sharp edge of DSAR practice. Article 15(1)(h) requires meaningful information about the logic involved, as well as significance and envisaged consequences, where Article 22 automated decision-making is involved. In Dun & Bradstreet Austria, Case C-203/22, the Court said the controller must describe the procedure and principles actually applied so the person can understand which personal data were used and how. Trade secrets can require balancing by a court or supervisory authority, but they do not justify a blank refusal to provide meaningful information.

UK subject access guidance uses similar operational vocabulary under the UK GDPR: recognize verbal or written requests, verify identity where needed, perform a reasonable search, provide information securely and intelligibly, handle third-party data carefully, and record reasons for refusal or withholding. California's CCPA/CPRA uses a "right to know" and access framework rather than GDPR terminology; it is adjacent, but it should not be cited as the same right with the same triggers, deadlines, or scope.

How It Works

A good DSAR process begins before the request arrives. The organization needs a route for recognizing requests, verifying identity when appropriate, searching systems, asking processors for relevant data, applying exemptions or limits carefully, and explaining what has been provided or withheld.

The search plan should start from the Records of Processing Activities, data map, retention schedule, vendor list, and AI system inventory. It should not depend on one product database if personal data also exists in logs, tickets, warehouses, vector indexes, evaluation samples, or third-party processors.

For AI systems, search scope is the practical question. Personal data may sit in product databases, prompt logs, vector indexes, CRM notes, evaluation datasets, human-review queues, vendor support tickets, fraud systems, experimentation tools, memory and personalization stores, or audit logs. If the organization cannot locate the data, the right of access becomes theoretical.

The search should include generated and inferred records where they relate to the person: risk labels, moderation outcomes, fraud scores, recommender profile fields, model-generated summaries, escalation notes, evaluator comments, and agent action traces. Whether each item must be disclosed depends on context, rights of others, and applicable limits, but it should first be found and classified rather than ignored because it came from an AI pipeline.

Responses should distinguish raw data from explanations. A person may receive the personal data undergoing processing and information about purposes, recipients, retention, rights, source, transfer safeguards, and qualifying automated decision-making. That response can support rectification, erasure, objection, portability, complaint, appeal, or litigation, but it is not itself a full model audit.

The response also needs a safety review. A chatbot transcript may contain another person's personal data. A fraud-investigation note may reveal detection methods. A model-evaluation example may contain confidential information. A refusal or redaction should be specific enough to be contestable, not a blanket claim that everything AI-related is proprietary, security-sensitive, or impossible to retrieve.

Governance and Safety

The governance value of a DSAR is that it tests whether an institution's privacy map is real. A controller that cannot find account histories, inference records, recipient identities, consultation logs, retention periods, or automated-decision information may also struggle with deletion, correction, breach response, DPIAs, or vendor oversight.

The safety limit is that access does not equal contestability. A person can receive data and still be unable to understand a model, challenge a score, or prove harm. DSARs need to be connected to Algorithmic Recourse, Notice and Appeal, and human review where automated systems affect rights, opportunities, or standing.

There is also an identity and security risk. A DSAR response can contain account histories, health records, employment records, child data, location traces, financial data, screenshots, messages, and inferred attributes. Controllers need requester verification, representative checks, secure delivery, redaction discipline, and an audit trail for what was disclosed or withheld.

Agentic and vendor-hosted systems make the governance test harder. A customer-support agent may read CRM data, a fraud model may write a score, an inference provider may retain logs, and a human-review vendor may annotate outputs. The controller still needs to know which party holds which personal data, whether it acts as processor or independent controller, and how a DSAR reaches that system without leaking secrets or other people's data.

DSARs can themselves be abused. A coerced or "enforced" access request can make a person obtain records for an employer, insurer, lender, landlord, or abusive party. The UK ICO treats forced subject access in defined contexts as a serious misuse of the right. AI systems that return rich personal histories, relationship records, or workplace traces should be designed so access supports the person rather than turning into extraction by someone else.

Failure Modes

Defense Pattern

Evidence Record

For AI-related systems, a DSAR evidence file should preserve the request, intake channel, identity-verification step, representative authority where relevant, request scope, clarification request if any, search terms and systems searched, processors contacted, data retrieved, exclusions applied, response date, extension notice if any, secure-delivery method, and the final response package.

Where the response involves AI traces, the record should identify model or system name, relevant logs, profile attributes, inference outputs, human-review notes, source systems, recipients or recipient categories, retention rules, transfer safeguards, and any automated-decision information provided. If the organization concludes that an embedding, score, prompt, classifier label, or model artifact is not personal data, that legal and technical reasoning should be recorded.

The evidence file should also record consultation evidence where relevant: when the person's record was accessed, by which system or role category, for what purpose, and whether the identity of individual staff members was disclosed, withheld, or replaced with a less intrusive explanation after balancing other rights.

The evidence file should also record what was withheld and why: other people's data, legal privilege, security-sensitive information, trade secrets, manifestly unfounded or excessive requests, or national-law exemptions. The reason should be specific enough for supervisory-authority or court review.

Source Discipline

Do not collapse access into explanation. Article 15 contains access rights and specified information duties; Article 22 and related provisions govern certain automated decisions. Public AI explanations, model cards, system cards, and audit reports can support accountability, but they are not substitutes for the personal-data access right.

Source type matters. EUR-Lex carries the GDPR legal text. EDPB guidelines interpret the right of access at EU level. CJEU judgments clarify legal meaning in concrete disputes; CJEU press releases are useful official summaries but not substitutes for the judgment in legal work. The ICO provides UK subject-access guidance. CPPA and California Attorney General materials describe California rights in their own framework. Vendor support articles can help locate data in a product, but they cannot define the legal scope of access.

For AI-related claims, name the data surface: prompt log, chat transcript, embedding, memory record, classifier label, profile field, moderation note, agent trace, inference-provider log, training sample, or evaluation example. "The model has data about me" is too vague for source discipline; the response should say which artifact exists, who controls it, why it was processed, and what legal limit was applied if it was withheld.

Spiralist Reading

A DSAR is a person asking the machine to show its memory.

The institution prefers the person as an object of processing: account, profile, risk, segment, vector, ticket, metric, suspect, lead, user. The access request reverses the gaze. It asks what the institution has kept, what it has inferred, where it sent the record, and how long the trace is meant to live.

For Spiralism, the demand is not mystical transparency. It is administrative friction placed where silent categorization would otherwise harden into standing, ranking, or exclusion.

Open Questions

Sources

Return to Wiki