figma guide
Designing vendor risk assessment and third-party security reviews UI in Figma: questionnaires, scores, and handoff
Design vendor risk assessment and third-party security review UI in Figma with intake forms, questionnaire status, risk scores, app linkage, and Dev Mode specs for enterprise Security admin.
- Published
- Updated
- Jul 18, 2026
- Read time
- 7 min
- Level
- Intermediate
Quick answer
Vendor risk assessment UI helps Security teams evaluate third-party apps, OAuth integrations, and data processors before approval. Design an intake queue for new vendor requests; questionnaire wizard (SOC2, ISO, custom) with save-and-resume; risk score with tier (Low / Medium / High / Blocked); linkage to app approvals and API keys; annual re-review calendar; and evidence attachment for auditor export via compliance exports. Start from the Figma guides hub and pair with DLP, webhooks, security posture, and Dev Mode handoff.
Who this is for
- Product designers building vendor intake, security questionnaire, and third-party risk dashboards for enterprise admin consoles.
- Design system teams aligning risk tiers with badges, progress indicators, and tables.
- Engineers implementing questionnaire schemas, scoring rules, re-review schedules, and app-install gates.
Vendor intake queue
| Column | Content |
|---|---|
| Vendor | Name + logo |
| Request type | New app / Renewal / Scope change |
| Requester | Member or Team Admin |
| Data access | Read / Write / Export / PHI tags |
| Status | Draft / In review / Approved / Blocked |
| Risk tier | Low / Med / High / — |
| Due | SLA countdown |
VendorIntakeQueue
├── Header: Third-party reviews · [ New assessment ] [ Export register ]
├── Filters: Status · Tier · Data class · Overdue
└── Row: Slack OAuth · Scope change · jane@ · High · Due 2 daysVerdict: intake should block app install until review completes when org policy requires it—show blocked state on marketplace approval row.
Assessment detail page layout
VendorAssessmentDetail
├── Header: Acme Analytics · Risk: Medium · Next review: 2027-01-15
├── Tabs: Questionnaire · Evidence · Integrations · History · Notes
├── ScoreSummary: 72/100 · 2 open findings · SOC2 Type II on file
├── LinkedIntegrations: OAuth app · 2 webhooks · 1 API key
└── Actions: [ Approve with conditions ] [ Block ] [ Request more info ]| Zone | Purpose |
|---|---|
| Score summary | Computed tier + trend vs last review |
| Open findings | Failed controls needing remediation |
| Integrations tab | Live links to app, webhooks, tokens |
| History | Prior assessments and tier changes |
Questionnaire wizard
Multi-step form with autosave—vendors or internal owners may complete over days:
| Step | Content |
|---|---|
| 1. Vendor profile | Legal name, HQ, subprocessors list |
| 2. Data handling | Categories, retention, encryption, region |
| 3. Certifications | SOC2, ISO 27001, upload reports |
| 4. Access model | OAuth scopes, API key usage, admin roles |
| 5. Incident history | Breaches last 24 mo, notification SLA |
| 6. Reviewer sign-off | Security Admin attestation |
QuestionnaireStep — Data handling
├── What data categories does this vendor access?
│ ☑ Customer PII ☐ Payment ☐ Health ☐ Source code
├── Data residency: US · EU · Other: ______
├── Encryption at rest: AES-256 ✓ (upload evidence)
└── [ Save draft ] [ Back ] [ Continue ]Use form patterns with validation states; long questionnaires need progress stepper in sidebar.
Risk scoring and tiers
Transparent scoring—not a black box:
| Factor | Weight | Example signal |
|---|---|---|
| Data sensitivity | 30% | PHI / PCI elevates tier |
| Access breadth | 25% | Org-wide OAuth vs user-level |
| Certification freshness | 20% | SOC2 > 12 mo old → penalty |
| Incident history | 15% | Breach in 24 mo → High minimum |
| Integration count | 10% | Many webhooks + keys |
| Tier | Policy effect |
|---|---|
| Low | Auto-approve with annual review |
| Medium | Security Admin approval + conditions |
| High | Owner approval + enhanced monitoring |
| Blocked | Install denied; existing integrations flagged |
ScoreBreakdownDrawer
├── Data sensitivity: High — customer PII export scope
├── Access: Medium — read/write calendar
├── Certs: SOC2 expires 2026-09-01 ⚠
└── Recommended tier: Medium · Approve with DLP monitorSurface vendor tier drift on security posture dashboard under Integrations domain.
Approve with conditions
Medium/High tiers often need guardrails—not binary approve/deny:
| Condition type | Example UI |
|---|---|
| Scope limit | Max OAuth scopes checkbox list |
| DLP mode | Force monitor on Confidential |
| Seat cap | Max 50 connected members |
| Re-review date | 6 mo for High, 12 mo for Medium |
| Owner attestation | Required checkbox for High |
ApproveWithConditionsModal
├── Approve Acme Analytics as Medium risk
├── ☑ Restrict to Marketing team only
├── ☑ DLP monitor on Confidential exports
├── Re-review: 2027-01-18
└── [ Confirm approval ] [ Cancel ]Conditions write to audit log and appear on integration detail pages.
Linkage to app marketplace and API keys
One vendor record may map to multiple technical integrations:
| Integration type | Link from assessment |
|---|---|
| OAuth app | App approval queue |
| API key | Token list filtered by vendor |
| Webhook | Event subscriptions |
| SCIM connector | Directory sync (if IdP vendor) |
When vendor tier drops to Blocked, show kill switch UI: revoke tokens, disable webhooks, uninstall app—with confirmation and audit trail.
Re-review calendar and renewals
| Signal | UI treatment |
|---|---|
| Review due in 30 days | Warning badge on queue |
| SOC2 report expired | Auto-escalate tier |
| Scope change detected | New assessment triggered |
| Overdue > 14 days | Posture gap on dashboard |
ReReviewCalendar
├── January: 4 vendors due · 1 overdue (highlight error)
├── Vendor: Legacy CRM · Overdue 18 days · Tier stale
└── [ Send reminder ] [ Start re-review ] [ Block integration ]Annual vendor register export for auditors—include tier, last review date, conditions, linked integration ids.
Comparison: vendor review vs app approval vs posture gap
| Surface | Question answered |
|---|---|
| Vendor assessment | ”Is this supplier trustworthy for our data?” |
| App approval | ”Can members install this OAuth app?” |
| Posture gap | ”What org controls are misconfigured?” |
A single OAuth request may spawn both app approval and vendor assessment—show linked records, not duplicate queues.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Approve/deny only—no conditions | High-risk apps run unrestricted | Approve-with-conditions modal |
| Questionnaire without autosave | Long forms abandoned | Draft save per step |
| Risk score hidden | Admins don’t trust tier | Breakdown drawer |
| Vendor decoupled from API keys | Shadow integrations | Link all integration types |
| No re-review calendar | Stale SOC2 on file | Due dates + posture gap |
| Tier change without audit | Compliance failure | Log tier transitions |
| Blocked vendor still syncing | Data exfil risk | Kill switch with revoke all |
| Same UI as member app store | Wrong mental model | Admin assessment ≠ marketplace browse |
| Evidence uploads without virus scan note | Security theater | Copy about scan + retention |
| Vendor register not exportable | Audit season scramble | One-click register PDF |
Recommended workflow
- Design intake queue with request types, SLA, and tier badges.
- Build questionnaire wizard with progress stepper and evidence uploads.
- Add score breakdown and tier recommendation with transparent weights.
- Create approve-with-conditions flow linking DLP, scope, and team limits.
- Wire integration tab to apps, keys, and webhooks.
- Add re-review calendar and overdue escalation to posture gaps.
- Annotate install gates and kill switch in Dev Mode.
FAQ
Does every OAuth app need a full vendor assessment?
Policy-dependent—Low-tier internal tools may use abbreviated checklist; PHI/PCI always full questionnaire.
Who fills the questionnaire—vendor or internal owner?
Both flows—external vendor portal link for SOC2 uploads; internal owner completes access-model steps.
Link to content classification?
Yes—data-handling step should reference org classification labels vendors may access.
Blocked tier vs DLP block?
Vendor block denies integration; DLP block restricts data movement—both can apply; show stacked badges.
Export for SOC2 vendor management evidence?
Vendor register PDF via compliance export—tiers, review dates, conditions, open findings.
Next steps
- Design third-party app approvals and marketplace UI in Figma — install gate linked to assessment
- Design API keys and personal access tokens UI in Figma — token inventory per vendor
- Design webhooks and event subscriptions UI in Figma — integration surface area
- Design security posture dashboard and compliance checklist UI in Figma — overdue review gaps
- Design DLP and external sharing restrictions UI in Figma — common approval condition
§ Keep reading