Extract data from Data Subject Access Requests (DSARs)
When a person asks a company for a copy of the personal data it holds on them, that inbound request is a Data Subject Access Request, and under GDPR Article 15 the organization has a legal clock to answer it. A DSAR is not a contract and not a risk study: it is a piece of correspondence, usually a letter or an email, sent by an individual (or a representative acting for them) to the data controller. It carries the sender and recipient, a subject line, a body that states what is being asked for, and a signature, which is why the request maps cleanly onto the RFC 5322 message structure. Privacy operations teams, Data Protection Officers, and legal intake staff all read the same few things off it before the response clock starts. What decides the workflow is identity, scope, and the deadline, not the prose. Before it hands anything over, the organization has to verify who is asking, so the verification method and any identification reference matter. Requesters usually narrow the ask to certain data categories and a time window or set of systems, and that scope defines the search. The response deadline, generally one month from receipt under GDPR (extendable by two further months for complex requests), is the field the whole intake queue is sorted by, and missing it is a regulatory exposure on its own. Talonic reads the DSAR and returns the requester, the receiving organization and its privacy contact, the data categories requested, the scope, the verification method, and the response deadline as typed fields, keeping the requested categories and the processing activities as tables. A request from Sofia Ricci to Northwind Retail Ltd, received 2026-05-04 with a response deadline of 2026-06-04, asking for identity, contact, purchase history, and marketing consent data from 2022-01-01 onward across all systems, loads into a privacy intake queue instead of a retyped email. This extraction structures what the request states and does not decide whether the request is valid or how the controller must answer it.
What gets extracted from Data Subject Access Requests (DSARs)
How extraction works for Data Subject Access Requests (DSARs)
A DSAR reaches a privacy team as a scanned letter, a forwarded email, a web-form export, or a PDF logged in a case system, and no two arrive laid out the same way. Talonic reads the request and resolves each value against the correspondence field set recorded in the Field Registry, which keeps the sender and recipient, the subject and body, the requester identity block, and the request parameters as separate fields rather than one paragraph. Data categories requested come back as an array, scope is held as its own field so a 2022-to-2026 window across all systems is legible, and the response deadline is parsed to ISO 8601 and can be checked against the one-month statutory window from the receipt date. The requested categories, the processing activities and their legal basis, the data recipients, and the request timeline each load as their own table. Every value returns with a confidence score and a source-region pointer under DIN SPEC 91491, so an intake analyst can trace a stated deadline or a requested category back to the line of the request. Overall, Talonic captures what the DSAR asks for and does not judge whether the request is valid, in scope, or how the controller should respond.
Sample extraction
A GDPR Article 15 access request emailed to a retailer
{
"document_number": "DSAR-2026-0451",
"document_date": "2026-05-04",
"letter_sender": "Sofia Ricci <sofia.ricci@example.com>",
"letter_recipient": "Northwind Retail Ltd, Privacy Team",
"letter_date": "2026-05-03",
"letter_subject": "Data Subject Access Request under GDPR Article 15",
"data_subject.name": "Sofia Ricci",
"data_subject.email": "sofia.ricci@example.com",
"data_subject.phone": "+44 20 7946 0321",
"data_subject.identification_number": "Passport 543210987",
"organization_name": "Northwind Retail Ltd",
"organization_contact": "Data Protection Officer, privacy@northwindretail.example",
"data_categories_requested": [
"identity data",
"contact data",
"purchase history",
"marketing consent records"
],
"scope_of_request": "2022-01-01 to 2026-05-04, all systems",
"request_purpose": "Verify what personal data is held and how it has been used",
"response_deadline": "2026-06-04",
"response_format": "electronic_portable",
"verification_method": "Certified passport copy attached",
"status": "acknowledged",
"salutation": "Dear Data Protection Officer",
"signatory": "Sofia Ricci",
"data_categories": [
{
"category_name": "Purchase history",
"requested": true,
"response_status": "retrieved"
},
{
"category_name": "Marketing consent records",
"requested": true,
"response_status": "pending"
}
],
"request_timeline": [
{
"event_date": "2026-05-04",
"event_type": "received",
"event_description": "Request received by privacy inbox"
},
{
"event_date": "2026-05-06",
"event_type": "acknowledged",
"event_description": "Acknowledgement sent, identity verification requested"
}
]
}Frequently asked
How is a DSAR different from a DPA or a DPIA?
A DSAR is an inbound request from an individual for their own data under GDPR Article 15. A DPA is the Article 28 contract between a controller and a processor, and a DPIA is an internal Article 35 risk assessment. Talonic reads each on its own schema and does not mix the three.
Does it capture the response deadline?
Yes. The response deadline is parsed to ISO 8601 and can be checked against the one-month statutory window that runs from the receipt date, so a request received 2026-05-04 with a 2026-06-04 due date surfaces at the top of the queue rather than being missed.
Can it read the requested data categories and scope?
The data categories requested return as an array and the scope, such as a 2022-to-2026 window across all systems, is kept as its own field, so the search that fulfils the request is defined from structured data rather than reread each time.
Does Talonic decide whether the request is valid?
No. It captures what the requester asks for, the identity they assert, and the verification they supplied. Whether the request is valid, in scope, or subject to an exemption is a decision for the controller and its Data Protection Officer, not the extraction.
Ready to extract from your own Data Subject Access Requests (DSARs)?
Author note
Reviewed by Talonic engineering, privacy schema review · last reviewed 2026-07-09
- Source: Talonic DSAR schema (seeded)