GDPR Contact Form Template
A data-subject request channel that documents itself — the right being exercised, the identity involved, and proof of authority when someone acts for another.
Use this form to exercise your data protection rights. Every request is logged with a timestamp, and we respond within the statutory period — typically one month.
The person whose data this request concerns.
The address we hold data under — it's how we locate your records.
When a data-subject request arrives by plain email, three problems start at once: nobody logged the date the statutory clock started, nobody confirmed which right is actually being exercised, and nobody checked whether the sender may lawfully act for the person named. This form fixes all three at intake — turning GDPR's scariest inbox event into a structured record your process can handle calmly.
Why these fields. The rights selector does more compliance work than it appears to: access, erasure, rectification, portability, and objection each trigger different internal procedures, and a request that names its right skips the clarification round-trip that eats a week of your response window. The self-or-representative question gates a proof-of-authorization upload through logic — data subjects acting for themselves never see it, while representatives cannot pretend they weren't asked; acting on an unverified third-party request is itself a breach, so this branch is protective in both directions. Rectification reveals a before-and-after field, because "correct my data" without the correction is an unfulfillable request. The email field asks specifically for the address the data lives under — the single detail that most accelerates locating records.
What we left out. Identity-document uploads for the data subjects themselves. Demanding passports up front is disproportionate for most requests and creates a new pile of sensitive data to protect; verify identity in the reply when the request's nature warrants it, as regulators actually recommend. Also legal-basis lectures and consent walls — the form's job is receiving the request, not debating it.
Who uses this. Any company with EU or UK users — SaaS products, e-commerce shops, newsletters, agencies holding client-side personal data — and privacy-forward companies elsewhere handling CCPA-style requests through the same disciplined channel.
Make it yours. Link this from your privacy policy where "contact us to exercise your rights" currently points at a bare email address. Every submission is timestamped in the responses view — that timestamp is your Article 12 evidence, and the CSV export is your request register when an audit or regulator asks. Notifications should reach whoever owns privacy internally the moment a request lands; a webhook can also open a tracked task automatically. Add your data-protection officer's details to the ending text if you have one.
Process, documented. The ending tells requesters the clock started and identity checks may follow. That sentence — sent automatically, logged permanently — is the difference between a compliance process and a compliance hope.
Frequently asked questions
Does the timestamp help with the one-month deadline?
Yes — every request is logged with its submission time in the responses view, giving you a clean record of when the statutory period began and evidence of your handling timeline.
Why is proof only required for representatives?
A logic rule reveals the upload only when someone acts for another person — that's where unverified requests become dangerous. Data subjects themselves are verified in the reply if needed.
Can this handle CCPA or other privacy regimes?
The structure transfers directly — rename the rights options to your applicable law's vocabulary in the editor. The logging, proof branch, and register export work identically.
How do we keep a register of all requests?
The responses view is the register — filterable by right exercised, with timestamps. Export CSV periodically for your compliance records or when your DPO asks.