Obtainer
INTAKE - THE FRONT DOOR

Subject Access Request Form: Publish a DSAR Form and Data Subject Request Portal

Your subject access request form is the one intake channel you control. Obtainer gives you a hosted DSAR form that timestamps the request, verifies who is asking, and starts discovery across your systems the moment it lands.

See pricing
Discovery across your systems Human redaction gate Helps you comply, not legal advice
Request Studio
Requester
Compiled the manifest and drafted the response - illustrative sample request
0
records found
0
systems scanned
Data manifest
Response draft

Assembling the cover letter from the template...

You approve what is disclosed before anything ships

Helps you comply, not legal advice

In short

A subject access request form, also called a DSAR form or data subject request form, is the intake page a company publishes so people can ask what personal data it holds about them. It is worth having, but it is worth knowing what it is not: no privacy law requires one, and none of them let you make it the only way in. Under the GDPR a request is valid however it arrives, including verbally and over social media, with no special wording. Under the CCPA a business that does not operate exclusively online must offer two or more designated methods, one of which has to be a toll-free telephone number, and a request that arrives outside those methods still counts. So the form is not a gate. It is a clean front door that gives you a timestamp, a verified requester, and a defined scope, which is exactly what the 45-day and one-month clocks need. Obtainer hosts that form, logs the request, and starts finding where the person's data actually lives while a human keeps control of what is disclosed.

Last updated August 2026

// CAPABILITY

What you get

SAR form, built for privacy, legal, and ops teams

A timestamp you can defend

Every submission is logged with the date and time it arrived, so the statutory clock starts from a record rather than from somebody remembering when the email came in. Deadline math is only as good as the receipt date behind it.

Verification built into intake

The form collects what you need to confirm the requester before you go looking, and handles authorized agent submissions, so you are not disclosing one person's data to another. Verification time comes out of your GDPR month, so it starts immediately.

Scope captured at the door

Structured fields ask which rights the person is exercising and which accounts or identifiers they use, so discovery starts from real search terms instead of a one-line email you have to chase.

Discovery starts on submission

Intake is not filing. When a request lands, Obtainer begins locating where that person appears across your systems and compiles a reviewable manifest, so the work is underway before anyone opens the ticket.

// 4 STEPS

How it works

From an intake request to a ready-to-review response in four steps

01

Publish the form

Put the request form on your privacy page and name it in your privacy notice, alongside the other submission methods your regimes require.

02

Log and verify

The submission is timestamped and the requester is verified to a standard that matches the sensitivity of what they are asking for.

03

Discover and compile

Obtainer searches your connected systems for that person and compiles what it finds into one reviewable source-system manifest.

04

Redact, approve, respond

A person reviews the manifest, redacts third-party data, and approves the reply before it ships. Obtainer helps you comply. It is not legal advice.

// THE TABLE

Reference

What each regime requires for how a person submits a request

The pattern across every one of these regimes is the same. None of them mandates a form, and none of them lets your form be the only route in. Publishing one is still the right call, because it is the only channel where you control the timestamp, the identity check, and the scope.

RegimeIs a form required?Methods you must offerIs an off-form request still valid?
GDPR and UK GDPRNoNone prescribed. A request is valid in any form it arrives.Yes. Verbal, letter, email to any employee, or social media all count, and the person does not have to say "subject access request" or cite Article 15.
CCPA, business not exclusively onlineNo, but a website method is expectedTwo or more designated methods, one of which must be a toll-free telephone number. If you run a website, one method must be through it.Yes. Under 11 CCR 7020 you must either treat it as if it had been submitted properly, or tell the consumer how to submit it properly.
CCPA, exclusively online with a direct relationshipNoAn email address is sufficient. No toll-free number is required.Yes. The same rule about mis-submitted requests applies.
Virginia, Colorado and the other state lawsNoOne or more secure and reliable means, described in your privacy notice, taking account of how consumers normally interact with you and your ability to authenticate them.Not addressed in the statutes. The safe operating assumption is yes, so route it into the same queue.
Authorized agent requests under the CCPANo, but your form should accept themYou may ask for proof the consumer gave the agent signed permission, verify the consumer directly, or have the consumer confirm the authority.Yes. You may not require a power of attorney for a consumer to use an authorized agent, outside the Probate Code sections 4121 to 4130 case.
// FAQ

Frequently asked

Questions teams ask about sar form

Is a subject access request form mandatory?

No. No privacy law requires you to publish a subject access request form, and none of them lets you make one compulsory. The ICO's guidance on recognising a SAR says you can invite people to use your standard process, but you should make it clear that using the form or online system is not compulsory. A form is worth publishing anyway, because it is the one channel where you control the timestamp, the identity check and the scope.

What should a subject access request form include?

At minimum: the requester's full name and contact details, which right they are exercising (access, deletion, correction, portability, or opt out), the identifiers they use with you such as account email or customer number, the jurisdiction they are a resident of, and whether they are submitting on their own behalf or as an authorized agent. Add a field for the time period or systems they care about, since a narrower scope is often faster for both sides. Then timestamp it, because the receipt date is what your DSAR deadline tracking runs on.

Can we require someone to use our DSAR form?

No. Under the GDPR there are no formal requirements for a valid request, so one made verbally, by letter, by social media or in an email to any employee is valid whether or not it uses your form. Under the CCPA, if a consumer submits a request outside your designated methods, 11 CCR 7020 requires you to either treat it as properly submitted or tell them how to submit it properly. Ignoring an off-form request is not an option under either regime.

How many ways must we let consumers submit a privacy request?

Under the CCPA it depends on how you operate. A business that does not operate exclusively online must provide two or more designated methods, and one of them must be a toll-free telephone number. If you maintain a website, one of the methods must be through it, such as a webform. A business that operates exclusively online and has a direct relationship with the consumer only has to provide an email address. The state laws that followed require one or more secure and reliable means described in your privacy notice.

Can we make someone create an account to submit a request?

No. A person who does not already have an account with you cannot be required to create one in order to make a request. If they do already have an account, you may require them to submit through it, but the same standard applies: the method has to be one they can actually reach. Building account creation into your intake flow is one of the most common ways a form quietly becomes non-compliant.

How do we handle a request from an authorized agent?

Accept it, then verify it. Under the CCPA you may require proof that the consumer gave the agent signed permission to submit the request, and you may require the consumer to verify their own identity directly with you or to confirm directly that they granted the permission. What you may not do is require a power of attorney, except where the consumer has granted one under Probate Code sections 4121 to 4130. Agent submissions arrive in bulk more often than individual ones, so build the check into DSAR identity verification rather than handling each by hand.

Does the deadline start when the form is submitted?

Yes, at receipt, not at verification. The GDPR one-month clock and the CCPA 45-day clock both run from when the request arrives, so the time you spend confirming who the person is comes out of your own window rather than being added to it. That is the practical argument for collecting verification data on the form itself. If a request reaches you outside the form, the clock still started when it arrived, which is why every channel needs to feed the same queue. See how the DSAR response deadline works for the extensions and the state-by-state variations.

Run a data subject access request end to end

Obtainer finds where a person's data lives across your systems, compiles it into one manifest, drafts the deadline-safe response, and tracks the GDPR and CCPA clock. You review, redact, and approve what gets disclosed. Helps you comply; not legal advice.