Key takeaway: Third-party risk is determined by what access you grant and what data you send. Assessing the vendor’s paperwork without constraining that access measures the wrong variable.
Why the Questionnaire Underperforms
The standard process sends a long spreadsheet, receives affirmative answers, files the result and approves the vendor. Every party understands the ritual.
The answers are supplied by whoever at the vendor handles security questionnaires, which is frequently a sales function working from an approved response library. Nothing is verified. The questions ask whether a policy exists, not whether it is followed, and a policy document satisfies the question either way.
Meanwhile the questionnaire is identical for a vendor receiving your full customer database and one receiving nothing but an email address. Effort is uniform where risk is not.
Assessing the Exposure Instead
The questions that determine your actual risk concern the integration rather than the vendor’s internal practice.
| Question | Why it matters more |
|---|---|
| What data do we send, at what granularity? | Defines breach impact directly |
| What access to our systems do they hold? | Defines lateral movement potential |
| Do they hold standing credentials or short-lived ones? | Determines exposure duration |
| Can we revoke access unilaterally and immediately? | Determines response capability |
| What happens to our data on termination? | Determines long-tail risk |
| Which of their subprocessors also receive it? | Reveals the real chain |
The subprocessor question is consistently the most revealing and the least asked. A vendor may be genuinely careful and pass your data to four downstream services with their own risk profiles. Your exposure is the union of all of them.
Standing credentials deserve equal attention. An integration holding a long-lived API key with broad scope is a permanent risk that does not depend on the vendor’s diligence — it depends on their weakest employee’s laptop.
Tiering by Impact
Uniform assessment wastes effort on low-risk vendors and under-examines high-risk ones. Tier by what a compromise would cost.
A vendor with production write access or bulk personal data warrants genuine scrutiny: reviewing an actual audit report rather than a questionnaire, examining penetration test summaries, negotiating notification timelines, and testing the revocation path. A vendor receiving nothing sensitive warrants a short standard review.
The tier should be determined by the integration design, and the integration should be designed to lower the tier. Sending aggregated rather than record-level data, granting read rather than write access, and scoping to one dataset rather than an account all reduce risk more reliably than any assessment finding.
Contracts and Monitoring
Two contractual terms matter disproportionately: a breach notification window short enough to be useful, and an audit or termination right you can actually exercise. Notification within seventy-two hours is meaningful; notification “promptly” is not.
After onboarding, most organisations stop paying attention. Access granted for a project persists after the project ends. Review integrations periodically and revoke what is unused, which is the same discipline service accounts need and receives the same neglect.
Watch for vendor ownership changes too. An acquisition can alter data handling practices, jurisdiction and subprocessor lists without any notification you would notice.
The Bottom Line
Design the integration to minimise data and access before assessing the vendor, tier assessment effort by actual impact, and insist on short-lived scoped credentials you can revoke yourself. Ask about subprocessors and termination handling, since those determine exposure more than any policy attestation.
