figma guide
Designing records of processing activities (ROPA) and data mapping UI in Figma: inventory, lawful basis, and retention
Design ROPA and data mapping admin UI in Figma with processing activity records, data flow diagrams, lawful basis tags, retention schedules, and DSAR linkage for Privacy teams.
- Published
- Updated
- Aug 03, 2026
- Read time
- 8 min
- Level
- Intermediate
Quick answer
A records of processing activities (ROPA) is the GDPR Article 30 register—and the operational backbone for DSAR fulfillment, DPIA scoping, and vendor reviews. Design a processing activity catalog with purpose, data categories, lawful basis, recipients, retention, and cross-border flags; a data mapping canvas showing flows between systems; and linkage fields that connect each activity to subprocessors, DSAR request types, and PIA/DPIA assessments. Start from the Figma guides hub and pair with DSAR portal, DPA hub, data retention policies, privacy settings, and Dev Mode handoff.
Who this is for
- Product designers building privacy ops consoles for B2B SaaS, fintech, or healthcare platforms.
- Design system teams standardizing activity cards, lawful-basis chips, and data-category tags across compliance modules.
- Privacy officers and DPOs who need ROPA accuracy tied to engineering reality—not a spreadsheet that rots after launch.
ROPA hub (internal admin overview)
ROPAHub — Acme Privacy · 127 processing activities · 14 stale >90 days
├── Header: Coverage 94% systems mapped · 3 activities missing lawful basis · Last export Aug 1
├── Actions: [ New activity ] [ Import from CMDB ] [ Export Art. 30 PDF ] [ Run gap scan ]
├── Tabs: Activity register · Data flows · Categories · Retention · DSAR links · Audit trail
├── Alert: PA-442 "Marketing analytics" · Subprocessor changed · Review due in 5 days
├── Filters: Business unit · Lawful basis · Contains special category · Cross-border transfer
└── Link: [DPA hub](/designing-data-processing-agreements-and-subprocessor-management-ui-in-figma/) · PIA registry · Trust center| Section | Purpose |
|---|---|
| Activity register | Canonical list of processing activities with required Art. 30 fields |
| Data flows | Visual map from collection → storage → sharing → deletion |
| Categories | Personal data types, special categories, pseudonymization flags |
| Retention | Per-activity schedules linked to auto-deletion jobs |
| DSAR links | Which request types touch which activities |
| Audit trail | Who changed lawful basis, retention, or subprocessors |
Verdict: ROPA UI is the source of truth Privacy shares with Engineering, Legal, and Sales—if DSAR fulfillment cannot trace a request to activities, the register is decorative.
Processing activity record (detail view)
ActivityDetail — PA-118 · Customer account management · Owner: @product-privacy
├── Identity: Name · Internal ID · Business unit · Product surface · Status: Active
├── Purpose: Provide SaaS account, billing, support · Plain language + legal summary
├── Data subjects: Customers · Prospects · Employees (support staff) · Multi-select
├── Data categories:
│ ├── Identity (name, email) · Contact · Financial (invoices) · Usage telemetry
│ └── Special category: None · Sensitive flags: Payment card (tokenized)
├── Lawful basis: Contract (Art. 6(1)(b)) · Legitimate interest assessment link
├── Recipients / subprocessors:
│ ├── Stripe · DPA signed · US transfer · [View in DPA hub]
│ └── Zendesk · Support tickets · EU region
├── Retention: Active account + 7 years invoices · See [retention policy RP-09]
├── Security measures: Encryption at rest · RBAC · Link [security posture dashboard]
├── Cross-border: US · SCC Module 2 · Transfer impact assessment TIA-03
├── DSAR mapping: Access · Delete · Portability · Restriction (partial)
└── [ Save draft ] [ Submit for DPO review ] [ Mark deprecated ]| Art. 30 field | UI pattern |
|---|---|
| Purpose | Short title + expandable legal description |
| Data categories | Controlled vocabulary tags; warn on free-text drift |
| Lawful basis | Single primary + optional secondary; chip color by type |
| Recipients | Subprocessor picker synced to DPA registry |
| Retention | Duration + trigger event (account closure, contract end) |
| Cross-border | Country chips + transfer mechanism badge |
| Security | Checklist + link to technical controls doc |
Every activity needs an owner and review cadence—show “last reviewed” and overdue badge like vendor risk assessments.
Deprecated activities stay visible with end date—do not hard-delete; DSAR historical requests may reference them.
Data mapping canvas
DataMapCanvas — Product: Acme CRM · View: Collection to deletion
├── Nodes: Web app · Mobile SDK · Postgres · S3 exports · Segment · Salesforce · Snowflake
├── Edges: Label with data category + lawful basis + encryption in transit
├── Collection points: Signup form · API · Import CSV · Highlight [forms patterns](/designing-forms-in-figma-inputs-states-and-handoff/)
├── Storage: Primary DB · Backups (90-day) · Analytics warehouse (aggregated)
├── Sharing: Subprocessor edges dashed until DPA verified
├── Deletion path: Account delete job · Backup purge · Warehouse TTL
└── Legend: Personal · Pseudonymized · Aggregated · Special category| Canvas element | Design note |
|---|---|
| Node types | First-party system, subprocessor, internal team |
| Edge labels | Minimize clutter—hover for full category list |
| Unmapped node | Red outline from CMDB import gap scan |
| Version diff | Side-by-side before/after when engineering changes architecture |
| Export | PNG for audit evidence + structured JSON for tooling |
The canvas complements the register—it answers “where does this email address go?” faster than scrolling table rows.
Pair unmapped flows with SIEM connector inventory when logs contain personal data not yet in ROPA.
Lawful basis and LIA linkage
LawfulBasisPanel — PA-118 · Primary: Contract
├── Basis options (radio): Consent · Contract · Legal obligation · Vital interests · Public task · Legitimate interest
├── Consent path: Link [cookie consent](/designing-cookie-consent-and-tracking-preference-ui-in-figma/) category · Withdrawal impact note
├── Legitimate interest: LIA document upload · Balancing test summary · Objection handling link
├── Special category (Art. 9): Explicit consent · Employment law · Sub-flag required
├── Change request: Switching basis requires DPO approval workflow
└── History: Contract → Legitimate interest blocked Aug 2025 · Legal comment attached| Basis | UI guardrail |
|---|---|
| Consent | Show consent source; block if CMP category disabled |
| Contract | Warn if processing exceeds contract necessity |
| Legitimate interest | Require LIA attachment before publish |
| Legal obligation | Cite statute field mandatory |
Switching lawful basis mid-life is high-risk—use approval states similar to DPIA gates.
Retention and deletion linkage
RetentionLink — PA-118 · Policy RP-09 · Account billing records
├── Schedule: 7 years from invoice date · Legal hold overrides pause timer
├── Systems affected: Postgres invoices · S3 PDFs · Stripe (processor retention note)
├── Deletion job: nightly_invoice_archive_purge · Last run Aug 2 · 0 errors
├── DSAR impact: Delete request may retain invoices if legal obligation basis applies—surface in [DSAR workspace](/designing-data-subject-access-request-and-gdpr-portal-ui-in-figma/)
└── [ Edit schedule ] [ View legal hold banner ] [ Open data retention admin](/designing-data-retention-policies-and-auto-deletion-ui-in-figma/)Retention UI must show conflicts: user requests erasure vs legal obligation to retain tax records—display resolution copy for both admin and data subject views.
Link auto-deletion failures to audit log and compliance exports when regulators request proof of deletion.
DSAR and PIA integration
IntegrationPanel — PA-118 · Downstream links
├── DSAR request types: Access (full) · Delete (partial—retain invoices) · Portability (profile JSON)
├── Fulfillment checklist auto-populated in [DSAR admin workspace](/designing-data-subject-access-request-and-gdpr-portal-ui-in-figma/)
├── PIA/DPIA: DPIA-2024-07 attached · Next review Mar 2027
├── High-risk flag: No · Special category: No · Automated decision-making: No
└── Trust center: Public summary paragraph · Sync to [trust center CMS](/designing-trust-center-and-security-documentation-ui-in-figma/)| Link | Why it matters |
|---|---|
| DSAR types | Analysts know which systems to query per request |
| PIA registry | New activity triggers DPIA if thresholds met |
| Subprocessor changes | Auto-create review task when DPA hub updates vendor |
| Trust center | Marketing-facing processing summary stays aligned |
When DSAR post mentions “Portal disconnected from ROPA,” this integration is the fix—design the bidirectional link in both UIs.
Handoff checklist (Dev Mode)
- Activity — id, name, status, owner, business_unit, last_reviewed_at.
- Purpose — short_description, legal_description, data_subjects[].
- Categories — personal_data_types[], special_category_flag, sensitive_flags[].
- Lawful basis — primary_basis, secondary_basis, lia_document_id.
- Recipients — subprocessor_ids[], internal_teams[].
- Retention — policy_id, duration_rule, trigger_event, legal_hold_override.
- Transfer — countries[], mechanism (SCC, adequacy, BCR), tia_id.
- DSAR mapping — request_types[], partial_denial_notes.
- Flow node — system_id, node_type, position, connected_edges[].
- Accessibility — register table sortable; canvas has list alternative view.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| ROPA as static PDF only | Cannot drive DSAR or deletion jobs | Structured admin register + export |
| Free-text lawful basis | Inconsistent Art. 6 claims | Controlled basis picker + LIA gate |
| Subprocessors not synced | Article 30 incomplete | Live link to DPA hub |
| No owner or review date | Stale after product launch | Overdue badges + quarterly review queue |
| Canvas disconnected from register | Two conflicting truths | Single system IDs on nodes |
| Missing DSAR mapping | Slow fulfillment | Auto-checklist per request type |
| Retention without system binding | Deletion never runs | Link to retention job IDs |
| Special category buried in notes | Art. 9 violations | Explicit flag + DPIA trigger |
| Deprecated activities hidden | Historical DSAR gaps | Archive state with end date |
| Public trust center out of sync | Regulatory mismatch | Publish subset from same record |
Recommended workflow
- Design activity register with Art. 30 required fields and DPO approval states.
- Build data mapping canvas with CMDB import and gap scan alerts.
- Wire lawful basis panel with LIA and consent source links.
- Connect retention schedules to auto-deletion admin.
- Link DSAR request types so fulfillment checklists auto-populate.
- Sync subprocessors from DPA hub and trigger review tasks on vendor changes.
- Export Art. 30 register for audits and compliance evidence.
FAQ
ROPA vs PIA/DPIA registry?
ROPA lists all processing activities (Article 30). DPIA is an impact assessment for high-risk processing—a subset of activities link to one or more DPIA records.
How does ROPA help DSAR fulfillment?
Each request type maps to activities → systems → export scripts. Analysts start from the checklist instead of tribal knowledge.
Engineering CMDB import?
Allow system nodes to import from service catalog; Privacy enriches with categories, basis, and retention—show unmapped systems in red.
US state laws without Article 30?
Many teams maintain one processing inventory with jurisdiction tags (GDPR, CPRA, etc.)—filter views, single backend.
Link to cookie consent?
Consent-based activities must reference CMP category and policy version—changing banner categories flags affected ROPA rows for review.
Next steps
- Design DSAR and GDPR portal UI in Figma — fulfillment driven by activity mapping
- Design privacy impact assessment and DPIA workflow UI in Figma — high-risk activity assessments
- Design data processing agreements and subprocessor management UI in Figma — recipient sync
- Design data retention policies and auto-deletion UI in Figma — retention enforcement
- Design trust center and security documentation UI in Figma — public processing summaries
§ Keep reading