Skip to main content
Identity Authority
Category: Governance & Compliance

Subject Access Request

Also known as: SAR, Data Subject Access Request, DSAR
Simply put

A Subject Access Request is a request an individual makes to an organization asking for a copy of the personal data that the organization holds about them. It gives people a way to see what information a company has collected on them and, in many cases, to exercise related rights over that data. The organization receiving the request is responsible for locating and providing the requested personal data.

Formal definition

A Subject Access Request (SAR), also called a Data Subject Access Request (DSAR), is a formal request submitted by an individual (the data subject) to a data controller for a copy of the personal data the controller holds about them, typically supplied as a copy of the data rather than the original documents. According to the evidence, the request is directed to the organization acting as data controller and may accompany other individual rights over that personal data; the evidence does not specify the governing regulation, required response timeframes, or format, so those details are out of scope here. Note that a SAR is a privacy and data-governance process concerning disclosure of held personal data, and is distinct from runtime authentication or authorization mechanisms that verify a principal's identity or determine access to systems.

Why it matters

Subject Access Requests give individuals a direct mechanism to see what personal data an organization holds about them, making them a cornerstone of data-subject rights and organizational transparency. For the organization acting as data controller, the ability to receive, locate, and fulfill these requests is a measure of how well it understands and governs the personal data it collects. A SAR effectively tests whether an organization can find all the personal data tied to a single individual across its systems, which is often harder than it appears when data is spread across directories, applications, logs, and backups.

For IAM and identity governance teams, SARs matter because personal data is frequently entangled with identity data such as directory attributes, account records, and access histories. Responding accurately depends on knowing where an individual's data lives and being able to correlate records back to the correct data subject. Weak data mapping or fragmented identity stores can make it difficult to compile a complete and accurate response, which raises both compliance and operational risk.

It is worth emphasizing that a SAR is a privacy and data-governance process concerned with disclosing held personal data, not a runtime access-control mechanism. It does not authenticate a principal into a system or determine what a user may do once inside; those enforcement concerns are separate. Conflating the two can lead teams to treat a disclosure obligation as an access-management function, which it is not.

Who it's relevant to

Compliance and Privacy Officers
They own the obligation to respond to Subject Access Requests and must ensure the organization can locate and disclose the personal data it holds about an individual. They typically coordinate the end-to-end handling of a request across teams, though the specific regulatory requirements governing that process are not detailed in the available evidence.
Identity Governance and Administration (IGA) Leads
Because personal data is often bound up with identity data such as account records and directory attributes, IGA leads help ensure data can be mapped and correlated back to the correct data subject. Strong data mapping supports accurate and complete responses when a request arrives.
IAM Engineers and System Administrators
They operate the directories, applications, and stores where personal data associated with individuals resides. Their knowledge of where identity-linked data lives is often essential to locating the full set of personal data a SAR asks for, even though the SAR process itself is distinct from the authentication and authorization systems they manage.
Data Subjects (Individuals)
These are the people who submit the request to obtain a copy of the personal data an organization holds about them. The SAR is the mechanism through which they exercise this right, and per the evidence it may accompany other rights they hold over their personal data.

Inside SAR

Data subject identity verification
The step of confirming that the requester is the individual whose personal data is being requested, or an authorized representative. In most deployments this is a distinct identification and authentication step performed before any data is disclosed, to prevent unauthorized access under the guise of a legitimate request.
Scope of personal data
The set of personal data held about the data subject that must be identified and disclosed, which depending on the applicable regulation and configuration may span multiple systems, directories, and data stores rather than a single identity record.
Processing metadata
Contextual information often required alongside the data itself, such as the purposes of processing, categories of data, and recipients or categories of recipients, depending on the governing regulation and organizational policy.
Fulfillment workflow
The operational process for receiving, tracking, and responding to a request within any applicable statutory timeframe. This is typically an identity governance and administration (IGA) style lifecycle concern rather than a runtime access-enforcement mechanism.
Response delivery
The mechanism for returning the collected data to the verified data subject in an accessible form, which should itself be protected to avoid disclosing personal data to an unintended party.

Common questions

Answers to the questions practitioners most commonly ask about SAR.

Is a Subject Access Request the same as authenticating a user before granting them access to a system?
No. A Subject Access Request (SAR) is a data-protection right under regimes such as the GDPR that lets an individual (the data subject) request the personal data an organization holds about them, along with information about how it is processed. It is unrelated to the authentication step that verifies who a principal is at runtime, and it is not the same as the authorization step that determines what a principal may do. The term 'subject' here refers to the data subject in privacy law, not to a security subject or principal in an access-control policy. The two concepts share vocabulary but belong to different domains.
Does fulfilling a Subject Access Request just mean querying an LDAP directory or an identity store for a user's profile?
Not typically. Personal data relevant to a SAR is usually spread across many systems beyond the identity directory, which may include application databases, logs, backups, ticketing systems, and third-party processors, depending on the deployment. An identity directory such as an LDAP store or an IGA platform's identity repository may hold some in-scope attributes, but treating the directory as the sole source risks returning an incomplete response. Scoping a SAR is a data-discovery and governance exercise, not a single directory lookup.
Before responding to a SAR, how should we verify that the requester is actually the data subject they claim to be?
Requester verification is generally required so that personal data is not disclosed to the wrong party, but the appropriate assurance level depends on the sensitivity of the data and your legal and regulatory guidance. In many deployments organizations reuse existing authentication mechanisms for account holders, and apply additional identity-proofing steps for requests made outside an authenticated session. Note that identity verification here is a distinct step from authenticating routine access; the goal is confirming the requester corresponds to the data subject. Legal counsel typically determines what verification is proportionate, so the exact method is out of scope for a purely technical definition.
How can we locate all of a data subject's personal data across systems for a SAR?
Locating in-scope data usually depends on maintaining a data inventory or data map that records where personal data resides and which identifiers link records to a subject. In most deployments a stable correlation identifier helps join records across applications, directories, and logs, though matching may be imperfect where systems use different keys. Automated discovery tooling can assist, but the completeness of a response depends on the accuracy of the underlying inventory and the coverage of connected systems, which varies by organization.
What role can SCIM or IGA tooling play in supporting SAR fulfillment?
SCIM is a provisioning protocol for managing identity resources across systems, and IGA platforms manage lifecycle concerns such as provisioning, access reviews, and certification. These can help by centralizing knowledge of which accounts and attributes exist for a subject across connected applications, which may aid discovery for a SAR. However, they are administration and governance tools rather than purpose-built SAR-response mechanisms, and they typically do not cover non-identity data stores such as application content, logs, or backups where additional personal data may live.
Should SAR handling be treated as an IGA governance process or as a runtime enforcement concern?
SAR handling is generally a governance and data-management process rather than a runtime access-enforcement concern. It does not involve a policy decision point, policy enforcement point, or token validation at the moment of access; instead it concerns discovering, compiling, verifying, and delivering personal data in response to a request within a defined timeframe. In many deployments it is operated as a workflow with defined ownership, audit logging, and legal oversight, and it should be kept distinct from the real-time PDP/PEP mechanisms that authorize access.

Common misconceptions

A Subject Access Request is fulfilled by authenticating the user, so successful authentication is enough to release the data.
Authentication only verifies who the requester is; it does not by itself determine what data they are entitled to receive. Fulfilling a request also involves authorization decisions and, typically, a governance-driven process to gather and disclose the appropriate personal data.
Handling Subject Access Requests is a runtime access-enforcement function that can be delegated to a PDP/PEP.
In most deployments a Subject Access Request is an identity governance and administration concern involving request intake, tracking, and data collection, which is distinct from real-time enforcement components such as a policy decision point or policy enforcement point.
The identity in a single directory or token contains all the personal data needed to answer the request.
Depending on the deployment, personal data about a subject may be spread across multiple directories, applications, and data stores, so relying on a single LDAP record or token claim set is typically insufficient to satisfy the full scope of a request.

Best practices

Verify the requester's identity as a distinct step before disclosing any data, and treat identification and authentication separately from the authorization to release specific personal data.
Define and document the full scope of systems and data stores that may hold personal data, since data about a subject is typically distributed across more than one repository.
Manage requests through a governed workflow that tracks intake, fulfillment, and response within any applicable statutory timeframe, keeping this lifecycle process separate from runtime enforcement components.
Protect the response delivery channel so that collected personal data is returned only to the verified data subject or their authorized representative.
Include required processing context, such as purposes and recipients, where the applicable regulation and configuration call for it, rather than returning raw data alone.
Confirm the exact obligations against the governing regulation and organizational policy, and explicitly mark any details that vary by jurisdiction or deployment rather than assuming a single standard applies.
Promotional banner for the Penetration Report Template Kit