A vendor-risk interview case: assess the service before the questionnaire

Start a vendor-risk case by defining the service, the information it will handle, its access and the business dependency it creates. A completed questionnaire cannot establish that an assessment covers the proposed use if that use is still unclear.

The fictional case below uses the same supplier in two different situations. The point is to practice changing your evidence request when the service changes, rather than assigning a fixed risk label to a supplier's name.

Two uses of the same supplier

Fictional Bellwether Design is considering Larch Cloud. The business sponsor presents two options:

The supplier has returned a questionnaire and a report covering its document-viewing product. The proposed production workspace includes editing and external sharing. The package does not establish whether those features fall within the report's assessed scope.

No conclusion about the supplier's overall safety follows from those facts alone. They identify the first gaps to investigate.

Write the questions that change the decision

For option A, confirm that the files are genuinely synthetic, that staff will not upload client material, and that the workshop needs no connection to company systems. Ask who can change those conditions. A limited pilot loses its defining boundary if users can quietly turn it into production use.

For option B, clarify the categories of client information, expected users, external-sharing model and proposed identity connection. Ask the sponsor what interruption would affect, how work could be recovered, and who owns the decision to proceed. These answers help scope subsequent security, contractual and operational review.

Request assurance material that addresses the actual product and relevant period. If the supplied report covers only document viewing, ask the supplier to explain the relationship to editing and sharing. Record the unanswered scope question rather than treating the existence of a report as sufficient.

This is an illustrative starting point, not a complete onboarding checklist. The organization's requirements and the proposed use determine the assessment.

Make a conditional recommendation

Here is a possible interview response:

I would separate the synthetic workshop from the production workspace. For the workshop, I would confirm and document the data and access restrictions, the owner responsible for enforcing them, and the approval required for any change in use. For production, I would request evidence covering the actual workspace features and clarify data handling, access and continuity needs before making a recommendation. I would give the authorized decision-maker the remaining gaps and options; I would not treat a questionnaire response or a report for a different service as approval.

That response does not say the workshop is automatically approved. It explains a potentially narrower option and the conditions that would need to be established under the organization's process.

Handle commercial pressure directly

The sponsor says, “We have already paid for the first month.” Acknowledge the cost and ask about the decision deadline. Then show what remains unresolved and whether a bounded use can meet the immediate need.

A useful handoff might state: “The current package does not establish assurance coverage for editing and external sharing. The sponsor needs a production decision by Friday. Supplier clarification is requested for Wednesday. The synthetic workshop is a separate option subject to its stated restrictions and approval.”

Avoid a vague “security is blocking the project” summary. Identify the exact missing evidence, the action owner and the decision the gap affects. Avoid promising that Wednesday's response will necessarily resolve it.

Revise when the proposed use changes

Suppose the workshop facilitator now requests one real client file “to make the demo useful.” That changes an assumption supporting option A. Reopen the data-scope question and route the change through the appropriate review. Do not keep using the synthetic-data rationale after its condition is removed.

Record the change explicitly: the old scope, new request, assessment implication and next owner. This produces a more useful portfolio artifact than an unsupported red/amber/green label.

Background and further practice

NIST SP 1305 discusses using the Cybersecurity Framework to establish supply-chain risk management capability and communicate supplier requirements. It provides background for scoping the work; the organizations, options and responses here are our original fictional exercise.

Use the free evidence register for the report-scope gap. The third-party risk career guide offers another task-based introduction. For additional practice, inspect the genuine Interview Case Workbook preview, or browse all field notes.

For a comparison of free practice and the full book, read the vendor-risk workbook selection page.