Most of the pain in handling privacy requests is created at intake. A request that arrives as a vague email in a shared inbox has no timestamp, no request type, no identity signal, and no owner, so someone has to reconstruct all of that before the real work even starts, while the deadline runs. A well-built intake form fixes that at the source: it captures what you need to start the clock, verify the person, and route the request, in one clean submission. Get the form right and the rest of the process is downhill.

Here is what the law actually requires of your intake, the fields worth capturing, and the design traps that turn a form into a barrier. For the deadlines you are racing against once a request lands, see DSAR deadlines by law.

What the law requires you to offer

You cannot force everyone through a single web form. Both major regimes care about how many ways a person can reach you.

CCPA (California). Regulation section 7020 sets the rule. A business that operates exclusively online and has a direct relationship with the consumer needs to provide only an email address for requests. Everyone else must offer two or more designated methods, and one of them must be a toll-free telephone number. If you have a website, one method has to be through the site, typically a web form. You are also told to consider how you normally interact with consumers: if you deal with people in person, offer an in-person or printed option.

GDPR. There is no prescribed form at all. Article 12 says requests can come through any channel and must be easy to make, and you cannot require a specific form as a precondition. A web form is allowed and encouraged as one route, but you still have to accept a plain email or letter and treat it the same way.

The fields to capture (and the ones to leave off)

Capture enough to act, and nothing you do not need. A lean, well-structured form beats an exhaustive one.

Request type. Let the person pick: access, deletion, correction, portability, objection, opt-out of sale or sharing. This single field drives your whole downstream workflow and the deadline that applies.
Identity anchor. Email address at minimum. If the person has an account, tie the request to it. This is your verification starting point, not a demand for documents. See verifying a data subject's identity.
Whose data. A flag for whether the person is acting for themselves or as an authorised agent for someone else.
Enough to locate the record. For a business that knows customers only by email, that is the email. Resist adding fields "just in case"; every extra field is data you now have to protect.
Free-text detail (optional). A box for the person to narrow a broad access request helps you focus the search without delaying a clear request.

Leave off government ID uploads by default. Collecting sensitive identifiers at intake, before you even know if you have a genuine doubt about identity, inverts the GDPR proportionality rule and creates a new store of high-risk data.

Building the form, step by step

Show the rights that actually apply

A California visitor and an EU visitor have different rights. Present the request types relevant to the person's jurisdiction rather than a generic list, so nobody is offered a right they do not have or denied one they do.

Capture the receipt timestamp automatically

The deadline runs from receipt. Stamp every submission on arrival so the clock is attached to the request, not calculated later.

Verify the email before actioning

Send a one-time, expiring confirmation link to the address provided. Action the request only after it is clicked. This proves mailbox control without collecting anything new.

Route to a named owner

Send the verified request into a single register or inbox with one accountable owner, so it never sits unrecognised in a support queue.

Acknowledge and set expectations

Auto-confirm receipt and state the deadline. CCPA expects confirmation within 10 business days; a good acknowledgement also tells the person what happens next.

Accessibility is a requirement, not a nicety

The CCPA regulations require request methods to be easy to understand and accessible to consumers with disabilities, and they point to recognised industry standards, in practice WCAG. A form that only works with a mouse, has unlabeled fields, or fails at high zoom is not a compliant intake method. The same discipline you apply to a consent banner applies here: keyboard operable, proper labels and roles, sufficient contrast, and a sensible focus order. Under the European Accessibility Act, which applies from June 2025, this becomes a harder legal edge for many businesses selling to EU consumers.

Do not let the form become a dark pattern

An intake form can quietly defeat the right it is meant to serve. Watch for four failure modes regulators cite: forcing account creation to submit a request (not allowed for opt-outs), demanding excessive information beyond what you need to act, burying the form so it is hard to find, and making opt-out harder than opt-in. The Todd Snyder action turned partly on a request portal that required identity verification to opt out and then silently failed for 40 days. Symmetry and simplicity are the test. See dark pattern laws.

Where the form should live

Discoverability is part of compliance. Link to the intake from your privacy policy, your website footer, and, for California, the "Do Not Sell or Share My Personal Information" or "Your Privacy Choices" control. The do-not-sell link guide covers the exact titles and placement California requires. A privacy request portal that exists but cannot be found in two clicks fails the "clear and conspicuous" bar just as surely as one that does not exist.

How CookieBeam's privacy portal handles intake

CookieBeam ships an embeddable privacy portal you attach to a banner, so you do not build the form from scratch. It detects the visitor's region and shows only the request types that apply there: an EU visitor sees access, deletion, correction, portability, and objection; a California visitor sees access, deletion, do-not-sell, and correction; a Brazilian visitor also gets anonymisation. Each submission is captured with a timestamp and status in a request register, and the requester's email is verified with a time-limited token before the request is actioned. That covers the parts of intake that are mechanical and error-prone (jurisdiction logic, timestamping, email verification, routing) and leaves you to make the judgement calls the law reserves for a human. Pair it with the two-method rule where you are not an online-only business, and add your toll-free number as the second channel.

Privacy request intake checklist

Offer the required number of methods
Online-only businesses can use email alone; others need two methods including a toll-free number.
Accept plain emails too, especially under GDPR
You cannot require a specific form as a precondition to exercising a right.
Show the rights relevant to the visitor's region
Do not offer a California opt-out to an EU visitor, or hide GDPR rights from one.
Capture request type, identity anchor, and receipt timestamp
These three fields drive the workflow, the verification, and the deadline.
Verify by expiring email link, not document uploads
Keep intake minimal; escalate verification only for sensitive requests.
Meet WCAG accessibility for the form
Keyboard operable, labeled fields, sufficient contrast, sensible focus order.
Make the form findable and route it to a named owner
Link from the privacy policy, footer, and do-not-sell control.

Authoritative sources

A good form is the cheapest compliance you will buy

Every field you capture correctly at intake is work you do not repeat later, and every deadline you start on time is a complaint you never receive. Build the form to capture request type, an identity anchor, and a receipt timestamp, verify by expiring email link, and route to one owner. See DSAR handling for what happens after the form.