figma guide
Designing data subject access request (DSAR) and GDPR portal UI in Figma: intake, identity verification, and fulfillment
Design DSAR and GDPR rights portals in Figma with request intake forms, identity verification, SLA tracking, fulfillment packages, and admin queues for Privacy teams.
- Published
- Updated
- Aug 02, 2026
- Read time
- 9 min
- Level
- Intermediate
Quick answer
A data subject access request (DSAR) portal is how individuals exercise GDPR and similar privacy rights—access, deletion, correction, portability, restriction, and objection—through a structured intake and fulfillment workflow. Design a public request form with right-type selection and jurisdiction; identity verification before sensitive data is released; an admin queue with SLA countdowns (30 days GDPR default); and fulfillment packages (secure download, redaction notes, partial denial reasons). Start from the Figma guides hub and pair with privacy settings, compliance exports, PIA/DPIA workflow, DPA hub, and Dev Mode handoff.
Who this is for
- Product designers building privacy rights centers for B2C apps, B2B SaaS, or enterprise admin consoles.
- Design system teams aligning request forms, status trackers, and secure download patterns with forms and progress steppers.
- Privacy officers and Legal defining verification tiers, extension rules, and denial letter templates.
DSAR hub (internal admin overview)
DSARHub — Acme Privacy Ops · Open requests: 34 · Due this week: 9 · Overdue: 1
├── Header: Median fulfillment 18 days · Extension rate 8% · Denial rate 3%
├── Actions: [ Create manual request ] [ Bulk assign ] [ Export SLA report ]
├── Tabs: Intake queue · Verification · In progress · Awaiting approval · Completed · Templates
├── Alert: REQ-8842 overdue 2 days · Access · Enterprise customer · Escalated to DPO
├── SLA banner: GDPR 30-day clock · CCPA 45-day · Extensions logged with reason
└── Link: [Privacy settings self-serve](/designing-privacy-settings-and-data-management-ui-in-figma/) · Compliance exports · Audit log| Section | Purpose |
|---|---|
| Intake queue | New web/email requests awaiting triage |
| Verification | ID checks before data release |
| In progress | Cross-system data gathering |
| Awaiting approval | Legal/DPO review for denials or partial fulfillment |
| Completed | Closed with package hash and notification sent |
| Templates | Acknowledgment, extension, denial, fulfillment emails |
Verdict: DSAR UI spans public portal + admin ops—design both so status is never opaque to the data subject after submit.
Public request intake
DSARPortal — Submit a privacy request · acme.com/privacy/requests
├── Step 1: I am requesting as · [ Data subject myself ] [ Authorized agent ] [ Parent/guardian ]
├── Step 2: Request type (select one):
│ ├── Access / copy of my data (Art. 15)
│ ├── Delete my data (Art. 17)
│ ├── Correct inaccurate data (Art. 16)
│ ├── Export portable data (Art. 20)
│ ├── Restrict processing (Art. 18)
│ └── Object to processing (Art. 21)
├── Step 3: Account identifier · Email · Optional account ID · Region of residence
├── Step 4: Details · Free text · Scope (all data vs specific product)
├── Step 5: Verification method · Email OTP · Upload ID · Login to account
├── Submit → Reference REQ-8847 · Confirmation email · Do not include data in email
└── Footer: Privacy Policy · [Cookie settings](/designing-cookie-consent-and-tracking-preference-ui-in-figma/) · Contact DPO| Intake field | Design note |
|---|---|
| Request type | Plain language + legal article in helper text |
| Agent authorization | Upload power of attorney; separate workflow |
| Region | Drives SLA, verification tier, and template |
| Scope | Reduces over-broad engineering queries |
| Reference ID | Prominent on confirmation and status page |
| No data in email | Security copy on every confirmation |
Use forms patterns with clear labels—“Delete” must confirm irreversibility in a follow-up modal.
Logged-in users should pre-fill from session and offer one-click requests in privacy settings—portal handles guests and agents.
Identity verification tiers
Verification — REQ-8847 · Tier 2 · Status: Awaiting ID upload
├── Tier 0: Logged-in session · Sufficient for self-serve export in app settings
├── Tier 1: Email OTP · Low-risk access for known email match
├── Tier 2: Government ID + selfie match · High-risk or agent requests
├── Tier 3: Notarized agent docs · Enterprise legal hold exceptions
├── Failed attempt: 2 of 3 · Lock 24h · Link [account recovery](/designing-suspicious-login-alerts-and-account-recovery-ui-in-figma/)
└── Privacy: Delete ID images within 30 days after verification · Document in UI copy| Tier | When to use | UX |
|---|---|---|
| Session | User already authenticated | Redirect to in-app privacy center |
| Email OTP | Email matches account | Code entry + resend timer |
| ID upload | Guest delete or large export | Drag-drop + progress + encryption notice |
| Agent | Third-party request | Separate upload + manual review queue |
Verification UI must explain why ID is needed and retention period for uploaded documents—link to privacy settings data retention copy.
Show verification status chip on request tracker: Pending · Verified · Failed · Manual review.
Request status tracker (data subject view)
RequestStatus — REQ-8847 · Access request · Submitted Aug 1, 2026
├── Timeline:
│ ├── ✓ Received · Aug 1 · Acknowledgment sent
│ ├── ✓ Identity verified · Aug 2
│ ├── → In progress · Gathering data from 6 systems · Est. completion Aug 20
│ ├── ○ Review · Legal redaction if needed
│ └── ○ Delivered · Secure download link (7-day expiry)
├── SLA: 26 days remaining (GDPR 30-day deadline)
├── Message thread: Privacy team note Aug 2 · "We extended search to backup archive"
└── Actions: [ Upload additional info ] [ Cancel request ] [ Contact DPO ]| Tracker state | User communication |
|---|---|
| Received | Auto-ack with reference ID and SLA |
| Verification needed | Clear CTA; do not start SLA until verified (jurisdiction-dependent—Legal defines) |
| In progress | Honest scope; no fake progress bars |
| Extension | Formal notice with reason before deadline |
| Partial fulfillment | Explain exclusions (third-party data, trade secrets) |
| Completed | Secure link; no attachment in email |
Use progress steppers for major phases—not per-database micro steps that leak internals.
Cancel request available until fulfillment ships; confirm in modal for deletion requests.
Admin fulfillment workspace
FulfillmentWorkspace — REQ-8847 · Assignee: @privacy-analyst
├── Data sources checklist:
│ ├── [x] Production DB user profile · Auto-export script
│ ├── [x] Support tickets (Zendesk) · Manual export · Redact third-party PII
│ ├── [ ] Marketing automation · Waiting on vendor · Due Aug 10
│ ├── [x] Analytics (aggregated only) · Excluded per policy · Note attached
│ └── [x] Backups · Legal approved narrow search · Aug 5–Aug 12 window
├── Redaction panel: Highlight rows · Reason code · Reviewer sign-off
├── Package builder: ZIP encrypted · Password via separate channel · Expiry 7 days
├── Denial draft: Art. 12(5) manifestly unfounded · Requires DPO approval
└── [ Mark ready for review ] [ Send extension notice ] [ Complete and notify ]| Workspace element | Handoff detail |
|---|---|
| Source checklist | Integrations list; owner per system |
| Redaction | Reason codes sync to audit log |
| Package | File manifest; checksum; download audit |
| Denial | Template with legal article and appeal path |
| Extension | +60 days max under GDPR with documented complexity |
Partial denials need plain-language explanation in the delivery email—not only legal citations.
Link fulfilled exports to compliance exports when litigation hold affects scope—show banner on request if hold applies.
Self-serve vs portal routing
RoutingRules — Where requests land
├── Logged-in + Access/Export/Delete → [Privacy settings](/designing-privacy-settings-and-data-management-ui-in-figma/) automated flows
├── Guest or Agent → Full DSAR portal with verification
├── Enterprise org admin → B2B flow · May affect multiple users · Legal review gate
├── Employee HR data → Separate HR privacy inbox · Not mixed with product DSAR queue
└── Duplicate detection: Same email + type within 30 days → Merge thread| Right | Self-serve candidate | Portal required |
|---|---|---|
| Access copy | Yes, if session verified | Guest users |
| Delete account | Yes with re-auth | Agent-initiated |
| Portability JSON | Yes | — |
| Object to marketing | Preference center + settings | Formal objection letter |
| Restrict processing | Rare; usually manual | Always portal + review |
Design consistent status language across self-serve and portal—users should not see different terminology for the same state.
Handoff checklist (Dev Mode)
- Request — id, type, jurisdiction, submitter_email, agent_flag, status, sla_deadline.
- Verification — tier, method, verified_at, id_document_retention_days.
- Timeline event — timestamp, phase, public_message, internal_note flag.
- Data source — system_id, export_status, redaction_required, owner.
- Package — download_url_ttl, encryption, manifest_file_list, checksum.
- Denial/extension — template_id, legal_basis, approver_role, sent_at.
- Notifications — email_template_keys; never attach fulfillment files.
- Accessibility — form errors linked; status timeline as ordered list for screen readers.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Fulfillment attached to email | Data breach vector | Secure portal download only |
| SLA clock starts before verification | Premature overdue alerts | Legal-defined start trigger per region |
| Opaque “in progress” for weeks | Regulatory complaints | Phase updates + extension notices |
| Same queue for HR and product data | Wrong fulfillment scope | Route by data domain |
| No duplicate merge | Repeated work; inconsistent answers | Detect same email + type |
| ID images stored indefinitely | Secondary privacy violation | Retention countdown in admin UI |
| Delete request without re-auth | Account takeover abuse | Step-up auth or OTP |
| Engineering raw DB dump | Over-disclosure | Manifest + redaction workspace |
| Denial without DPO/Legal gate | Invalid rejection | Approval state in admin |
| Portal disconnected from ROPA | Cannot map processing activities | Link request types to PIA registry categories |
Recommended workflow
- Design public intake with right types, agent path, and verification tier selection.
- Build status tracker with SLA visibility and secure messaging thread.
- Spec admin fulfillment workspace with source checklist, redaction, and package builder.
- Define routing between portal and privacy settings self-serve.
- Create email templates for ack, extension, denial, and delivery—no attachments.
- Wire audit trail to compliance exports for regulatory requests.
FAQ
DSAR portal vs in-app privacy settings?
Settings automate high-volume self-serve rights for logged-in users. Portal handles guests, agents, complex requests, and manual fulfillment—share status vocabulary.
Link to cookie consent?
Marketing opt-out may be instant via preference center; formal objection under Art. 21 may still need portal trail—Legal defines which rights use which path.
DPA hub when vendor holds data?
Fulfillment checklist includes processor requests—admin UI shows pending subprocessors (support tool, analytics vendor) with due dates.
CCPA vs GDPR copy?
Intake collects region and switches SLA text (45 vs 30 days), verification, and “Do not sell/share” cross-links—one portal, region-aware templates.
Enterprise B2B?
Org admin requests affecting employee lists need separate approval—do not merge with consumer queue; pair with team roles.
Next steps
- Design privacy settings and data management UI in Figma — self-serve export and delete
- Design cookie consent and tracking preference UI in Figma — marketing opt-out paths
- Design compliance exports and legal hold UI in Figma — litigation hold on fulfillment scope
- Design privacy impact assessment and DPIA workflow UI in Figma — ROPA linkage for processing categories
- Design trust center and security documentation UI in Figma — public instructions for submitting requests
§ Keep reading