figma guide
Designing privacy impact assessment and DPIA workflow UI in Figma: scoping, risk scoring, and approval gates
Design PIA and DPIA workflow UI in Figma with intake forms, risk scoring matrices, stakeholder review gates, mitigation tracking, and regulatory documentation exports.
- Published
- Updated
- Jul 31, 2026
- Read time
- 9 min
- Level
- Intermediate
Quick answer
Privacy impact assessment (PIA) and data protection impact assessment (DPIA) workflow UI is how product teams prove they evaluated privacy risk before shipping features that process personal data—especially high-risk processing under GDPR Article 35. Design an intake wizard that scopes data types, purposes, and legal bases; a risk scoring matrix with likelihood, severity, and mitigation tasks; approval gates for Legal/DPO sign-off before launch; and an assessment registry linked to your record of processing activities (ROPA). Start from the Figma guides hub and pair with privacy settings, DPA management, compliance exports, security posture dashboard, and Dev Mode handoff.
Who this is for
- Product designers building privacy-by-design tooling, feature launch checklists, or internal GRC modules.
- Design system teams aligning risk matrices, approval steppers, and intake forms with forms, progress indicators, and tables.
- Privacy officers, Legal, and engineering leads running DPIAs for new features, AI models, or cross-border data flows.
PIA hub (internal overview)
PIAHub — Acme SaaS · Open assessments: 8 · Awaiting DPO: 2 · Blocked launches: 1
├── Header: Required DPIAs this quarter 14 · Completed 11 · Avg cycle 12 days
├── Actions: [ Start new assessment ] [ Export registry ] [ Link to ROPA ]
├── Tabs: Intake queue · In progress · Awaiting approval · Completed · Templates · Settings
├── Alert: FEAT-4421 AI summarization · DPIA required · Launch blocked until DPO sign-off
├── Banner: GDPR supervisory consultation may be required for FEAT-4399 · Legal reviewing
└── Link: [Privacy settings patterns](/designing-privacy-settings-and-data-management-ui-in-figma/) · DPA hub · Vendor risk| Section | Purpose |
|---|---|
| Intake queue | New feature requests awaiting privacy triage |
| In progress | Active assessments with open mitigations |
| Awaiting approval | DPO/Legal sign-off gate |
| Completed | Archived with version and launch link |
| Templates | Standard, AI/ML, biometrics, children’s data |
| Settings | Triggers, risk thresholds, approver roles |
Verdict: PIA hub is the launch gate for privacy-sensitive features—engineering roadmap tools should show “DPIA status” alongside security review, not as a post-launch checkbox.
Intake wizard and scoping
PIAIntake — Step 3 of 6 · Data categories and legal basis
├── Feature: FEAT-4421 · AI meeting summarization · Owner: @product-maya
├── Trigger: Auto-flagged · Processes audio · New subprocessor candidate
├── Step 1 ✓ Feature summary and launch date
├── Step 2 ✓ Data subjects: Employees, meeting participants (may include non-users)
├── Step 3 → Data categories:
│ ├── [x] Voice/audio recordings · Retention: 90 days default
│ ├── [x] Derived transcript text · Linked to user account
│ └── [ ] Special category data · None expected — confirm in Step 4
├── Step 4: Legal basis · Legitimate interest vs consent · Jurisdiction matrix
├── Step 5: Risk factors · Automated decision-making, scale, vulnerable subjects
├── Step 6: Subprocessors · OpenAI API proposed · Link [vendor risk draft]
└── [ Save draft ] [ Submit for triage ] [ Escalate to full DPIA ]| Intake field | Why it matters |
|---|---|
| Feature ID | Traceability to Jira/Linear and launch calendar |
| Data categories | Drives DPIA requirement under Article 35 |
| Legal basis | Consent vs LI changes UI obligations in product |
| Retention | Must match privacy settings UX |
| Scale | ”All EU customers” elevates residual risk |
| New technology | AI/ML templates auto-apply stricter questions |
| Cross-border transfers | Links to DPA/subprocessor flow |
Use progress steppers with save-and-resume—intake spans multiple stakeholders over days.
Triage outcome: Lightweight PIA (document only) vs full DPIA vs supervisory authority consultation flag—show decision and rationale on summary page.
Risk scoring matrix
RiskMatrix — FEAT-4421 · Residual risk after mitigations: Medium
├── Inherent risks (before controls):
│ ├── Unauthorized access to audio · Likelihood: Medium · Impact: High · Score: 12
│ ├── Incorrect AI summary shared · Likelihood: Medium · Impact: Medium · Score: 9
│ └── Cross-border transfer without SCC · Likelihood: Low · Impact: High · Score: 8
├── Mitigations planned:
│ ├── Encryption at rest · Owner: @eng · Due: 2026-08-05 · Status: In progress
│ ├── Opt-in consent banner · Owner: @design · Due: 2026-08-01 · Status: Done
│ └── DPA with OpenAI executed · Owner: @legal · Due: 2026-08-10 · Status: Blocked
├── Residual risk: Medium · Acceptable threshold: Low-Medium for launch
├── DPO note: Residual medium acceptable if consent UX ships and DPA complete
└── [ Add risk ] [ Link mitigation ticket ] [ Recalculate scores ]| Matrix element | UI detail |
|---|---|
| Likelihood × Impact | 3×3 or 5×5 grid; color + label (not color alone) |
| Inherent vs residual | Toggle or side-by-side columns |
| Mitigation tasks | Linked tickets with owner and due date |
| Threshold line | Visual gate—above threshold blocks approval |
| Risk owner | Product owner accountable for acceptance |
| Version history | Recalculate when scope changes mid-assessment |
Heat-map cells should meet accessibility contrast—supplement color with “High (9)” text labels.
Mitigations must link to shippable work—design specs, eng tickets, or [DPA changes]—not vague “we will be careful” notes.
Approval gates and DPO sign-off
ApprovalGate — FEAT-4421 · Status: Awaiting DPO sign-off
├── Checklist (all required for launch):
│ ├── [x] Intake complete · Triage: Full DPIA
│ ├── [x] Risk matrix reviewed · Residual: Medium (accepted)
│ ├── [x] Mitigation: Consent UX · Verified in Figma file v12
│ ├── [ ] Mitigation: Subprocessor DPA · Blocked · CN pending
│ ├── [x] ROPA entry draft created · Activity ACT-088
│ └── [ ] DPO sign-off · Pending
├── Approvers:
│ ├── DPO: @privacy-lead · Action: [ Approve ] [ Request changes ] [ Escalate to SA consultation ]
│ ├── Legal: @legal-sarah · Approved 2026-07-28 with note on retention
│ └── Security: @sec-ops · Approved 2026-07-27
├── Launch integration: FEAT-4421 release flag · Blocked until DPO approve
└── Audit: All approvals timestamped · IP · Version of assessment PDF attached| Gate type | When required |
|---|---|
| Privacy triage | Every feature touching personal data |
| Full DPIA | High-risk triggers (AI, scale, sensitive data) |
| DPO sign-off | Mandatory for DPIA under Article 35(2) |
| Legal review | New legal basis or subprocessor |
| Supervisory consultation | Residual high risk after mitigations |
| Post-launch review | Scheduled 90 days after ship |
Design blocked launch state in engineering tools—a badge on feature flags: “DPIA: Awaiting DPO.”
DPO Request changes should reopen specific sections—not force full restart unless scope changed materially.
Assessment registry and ROPA linkage
PIARegistry — 142 completed · 8 in progress · Filter: [ AI features ] [ 2026 ]
├── ACT-088 · AI meeting summarization · Linked DPIA DPIA-2026-014
│ ├── Status: In progress · Launch target 2026-08-15
│ ├── Legal basis: Consent (EU) · Legitimate interest (US) — documented split
│ └── ROPA sync: Processing purpose, categories, retention, subprocessors
├── ACT-072 · Employee analytics dashboard · DPIA-2025-089 · Completed
│ ├── Review due: 2026-09-01 · Annual reassessment scheduled
│ └── Export: PDF for [compliance audit evidence](/designing-compliance-audit-evidence-and-certification-renewal-ui-in-figma/)
└── [ Export registry CSV ] [ Bulk schedule reviews ]| Registry field | ROPA alignment |
|---|---|
| Activity ID | Matches Article 30 record |
| Processing purpose | Plain language + legal wording |
| Data categories | Consistent taxonomy across product |
| Retention period | Synced to product config |
| Subprocessors | Links to DPA registry |
| DPIA reference | One-to-one or one-to-many |
| Next review date | Annual or on material change |
Completed assessments export to PDF for audit evidence and trust center summaries (sanitized—no internal risk scores public).
Templates for high-risk processing
TemplateLibrary — DPIA templates
├── Standard feature PIA · 12 questions · ~30 min
├── AI / ML processing · 28 questions · Mandatory DPO · Model card attachment
├── Biometric / voice · 22 questions · Supervisory consultation trigger
├── Children's data · COPPA/GDPR age gates · Parental consent UI checklist
├── Large-scale monitoring · Employee analytics · LI balancing test section
└── Cross-border expansion · New region · Transfer impact addendum| Template section | Product design output |
|---|---|
| Necessity & proportionality | Feature scope reduction options |
| Balancing test (LI) | Copy for privacy notice and in-product disclosure |
| Consent UX | Wireframes linked from assessment |
| Data minimization | Fields marked optional vs required in forms |
| Retention controls | Admin settings mockups |
| Individual rights | Export/delete flows in privacy settings |
Templates should pre-fill from product metadata when integrated with roadmap tools—reduce duplicate data entry.
Handoff checklist (Dev Mode)
- Assessment — ID, feature_ref, template_type, status, version, created_by.
- Intake answers — structured JSON per step; legal_basis per jurisdiction.
- Risk row — description, likelihood, impact, inherent_score, residual_score.
- Mitigation — ticket_link, owner, due_date, verification_status.
- Approver — role (DPO/Legal/Security), decision, timestamp, comment.
- Launch gate — feature_flag_id, blocked_until_approved boolean.
- ROPA link — activity_id; sync_status (draft/published).
- Export — PDF template regions for audit package.
- Accessibility — risk matrix readable by screen readers; form labels explicit.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| PIA after launch | GDPR violation; rework under fire | Launch gate blocks ship until DPO approves |
| Risk matrix without mitigations | Scores meaningless | Every high inherent risk requires linked task |
| DPIA in Google Doc parallel to tool | No launch integration; stale registry | Single system of record with export only |
| ROPA and DPIA use different data taxonomy | Audit gaps | Shared category picker component |
| Color-only risk heat map | Fails WCAG; misread by stakeholders | Numeric score + label on every cell |
| No annual reassessment trigger | Stale DPIA when feature scope creeps | Review due date on completed assessments |
| DPO sign-off without mitigation verify | Consent UX never shipped | Checklist item requires design/engineering proof |
| Public trust page shows internal scores | Reputation damage | Sanitized export for external docs only |
| AI features skip template | Highest-risk processing under-scoped | Auto-trigger AI template on model/API flag |
| Supervisory consultation undesignated | Regulatory surprise | Explicit escalation state and UI |
Recommended workflow
- Design intake wizard with auto-triggers from feature metadata (AI, new subprocessor, special categories).
- Build risk matrix with inherent/residual views and mitigation task linking.
- Create approval gates with DPO/Legal/Security roles and launch-block integration.
- Spec ROPA linkage so completed assessments populate processing records.
- Add template library for AI, biometrics, and cross-border scenarios.
- Wire audit export to compliance evidence and sanitized trust summaries.
FAQ
PIA vs DPIA — same UI?
PIA is the general privacy assessment. DPIA is the formal GDPR Article 35 assessment with mandatory DPO involvement. Use one workflow with template depth determining required steps—not separate products.
Link to privacy settings?
DPIA outputs product requirements for consent, export, delete, and retention—those screens should reference assessment ID in Dev Mode for traceability.
DPA hub when intake mentions new vendor?
Intake should spawn draft subprocessor change notice or link existing vendor—Privacy and Legal workflows stay connected.
Same as vendor risk?
Vendor risk evaluates supplier security. DPIA evaluates processing impact on data subjects—complementary; cross-link when subprocessor handles assessment data.
Supervisory authority consultation UI?
Add escalation state when residual risk stays high—document consultation request, authority response, and adjusted mitigations before launch approval.
Next steps
- Design privacy settings and data management UI in Figma — ship DPIA outcomes as product UX
- Design data processing agreements and subprocessor management UI in Figma — subprocessor changes from intake
- Design compliance audit evidence and certification renewal UI in Figma — DPIA PDFs as control evidence
- Design security posture dashboard and compliance checklist UI in Figma — privacy control health alongside security
- Design trust center and security documentation UI in Figma — public privacy summaries from approved assessments
§ Keep reading