Vendor Integration Security Review Workflow
Review new third-party integrations for data exposure, credential scope, and failure blast radius before connection, with renewal checkpoints.
Objective
Approve vendor integrations with bounded data flows, least-privilege credentials, and a known blast radius, re-reviewed on schedule.
Environment
- A proposed integration with a third-party service
- Data classification for what would be shared
- A security review owner and a renewal calendar
Steps
1. Classify the data to flow
Determine exactly which fields the integration sends and receives, classified against the data policy, since PII or credentials change the review depth.
Expected state: A field-level data flow exists with classification labels.
2. Scope credentials to least privilege
Issue vendor credentials scoped to exactly the integration's function: read-only where possible, webhook-specific keys, no account-level tokens.
Expected state: The credential cannot do anything the integration does not require.
3. Assess the blast radius
Model what happens when the vendor is breached, slow, or goes dark: which of our flows stall, which data leaks, what is the fallback.
Expected state: A written blast-radius statement covers breach, outage, and exit.
4. Verify their controls once, monitor continuously
Review the vendor's attestations (SOC 2, pen test summary) at onboarding, then monitor their posture signals and incidents on a schedule.
Expected state: Onboarding evidence is archived, and monitoring checks run at renewal.
5. Set renewal checkpoints with exit test
Schedule re-review annually, and test the exit path (credential revocation, data deletion confirmation, feature fallback) before renewal completes.
Expected state: Each renewal demonstrates the exit path still works.
Expected outcome
Vendor integrations with bounded data flows and least-privilege credentials, whose failure modes are documented, and whose exit path is tested at every renewal.
Verification
The integration's credential demonstrably cannot exceed its function; the exit test at last renewal revoked access and confirmed data deletion responses.
Every integration is two risks in one cable
A third-party connection adds the vendor’s security posture and the failure of the cable itself. Field-level data classification, least-privilege credentials, and a blast-radius statement bound both, and the renewal exit test keeps the escape route real.
integration: fraud-score-vendor (proposed)
data flow (field-level):
OUT: order_id, amount_cents, billing_region, ip_prefix
(no PII direct -- billing_region = coarse)
IN: score 0-100, reason codes
credential: webhook-specific key, source IP allowlist
(cannot read our data, cannot call other endpoints)
blast radius:
vendor breached: order metadata + coarse region (low)
vendor slow: checkout adds 1.2s -- fallback: skip score
vendor dark: manual review queue (documented)
renewal (2027-04): exit test -- revoke key, confirm deletionField-level classification finds the accidental PII
Vendors request “order data” and receive full customer records because nobody enumerated fields. The field-level pass catches the email inside the shipping object and the IP that is more identifying than intended, before the contract makes it awkward to remove.
The exit test is the renewal’s real content
Renewals that only re-read last year’s documents measure nothing. Revoking the credential and confirming the deletion response, while running the fallback path, proves the exit route still functions — which is the only fact that matters when the relationship ends abruptly.