Vendor Risk Assessment Prompt Template

This prompt is designed for procurement and security teams who need to assess vendor risk from RFP responses, security questionnaires, and due diligence documents. It uses few-shot examples to teach the model how to identify risk indicators, extract supporting evidence, and assign a risk tier. Use this when you need consistent, evidence-backed risk assessments that follow your organization's risk taxonomy. The primary job-to-be-done is accelerating triage: turning a stack of vendor documents into a structured risk signal that a human reviewer can verify, challenge, or approve without reading every page from scratch.

The ideal user is a security analyst, vendor risk manager, or procurement specialist who already understands their organization's risk appetite and control framework. The prompt assumes you have defined risk tiers (e.g., Low, Medium, High, Critical) and can supply a few labeled examples that demonstrate the boundary between each tier. It works best on structured or semi-structured inputs—completed questionnaires, RFP sections, SOC 2 reports, or security whitepapers—rather than raw contracts or scanned handwritten notes. The model extracts discrete risk indicators (e.g., 'no evidence of encryption at rest,' 'sub-processor list not disclosed') and maps them to your tier definitions, producing a traceable assessment where every risk signal is anchored to a source quote.

Do not use this prompt as a replacement for human security review. It is a triage and evidence-extraction accelerator that surfaces signals for human decision-makers. It is not appropriate for generating final approval decisions, for vendors where the risk assessment carries regulatory liability without human sign-off, or for domains where the model has no access to your internal control requirements. If your risk taxonomy changes frequently, you will need to update the few-shot examples to prevent drift between the model's learned boundaries and your current definitions. Pair this prompt with a human-in-the-loop review step, log every assessment with its evidence chain, and run periodic eval checks to confirm that risk tier assignments remain consistent as vendor document formats evolve.

This prompt template is designed to be pasted directly into your orchestration layer. It instructs the model to act as a vendor risk analyst, using provided examples to classify a vendor's RFP response into a risk tier and extract supporting evidence. The template uses square-bracket placeholders for all dynamic inputs, which you must replace with real data before sending the request to the model. The structure separates the system role, the few-shot examples that teach the classification pattern, and the final input to be assessed.

codeCopy
SYSTEM:
You are a Vendor Risk Analyst. Your task is to assess a vendor's response to a Request for Proposal (RFP) and classify the overall risk tier based on the provided examples. You must extract specific evidence from the response to justify your classification. Do not use outside knowledge. If the evidence is insufficient, classify the risk as 'INSUFFICIENT_DATA'.

[OUTPUT_SCHEMA]
Respond in valid JSON with the following fields:
- "risk_tier": string (enum: "LOW", "MEDIUM", "HIGH", "CRITICAL", "INSUFFICIENT_DATA")
- "risk_summary": string (a one-sentence summary of the primary risk driver)
- "evidence": array of strings (direct quotes or specific paraphrases from the vendor response that support the risk tier)
- "missing_information": array of strings (list of key data points not found in the response that would be needed for a more confident assessment)

[EXAMPLES]
---
Input: "Our company has been SOC 2 Type II certified for the past 5 years with no audit exceptions. We host all data in AWS US-East-1 and perform annual penetration tests by a CREST-certified third party. Our incident response plan is tested quarterly."
Output: {
  "risk_tier": "LOW",
  "risk_summary": "Strong, long-standing security posture with independent validation and proactive testing.",
  "evidence": [
    "SOC 2 Type II certified for the past 5 years with no audit exceptions",
    "host all data in AWS US-East-1",
    "annual penetration tests by a CREST-certified third party",
    "incident response plan is tested quarterly"
  ],
  "missing_information": []
}
---
Input: "We take security seriously. Our team follows best practices for data protection. We have a firewall and use encryption. We've never had a major breach."
Output: {
  "risk_tier": "HIGH",
  "risk_summary": "Vague, unverifiable claims with no evidence of formal security controls or independent audits.",
  "evidence": [
    "We take security seriously",
    "Our team follows best practices for data protection",
    "We have a firewall and use encryption",
    "We've never had a major breach"
  ],
  "missing_information": [
    "Specific compliance certifications (e.g., SOC 2, ISO 27001)",
    "Results of independent security assessments or penetration tests",
    "Details on encryption standards and key management",
    "Documented incident response and disaster recovery plans"
  ]
}
---
Input: "We are a startup in stealth mode. Our product is pre-beta. We don't have formal security certifications yet but plan to pursue SOC 2 next year. We use Google Drive for internal documents."
Output: {
  "risk_tier": "CRITICAL",
  "risk_summary": "Pre-product startup with no security program, no certifications, and use of consumer-grade tools for business data.",
  "evidence": [
    "startup in stealth mode",
    "product is pre-beta",
    "don't have formal security certifications yet",
    "use Google Drive for internal documents"
  ],
  "missing_information": [
    "Any existing security controls or architecture",
    "Data handling and retention policies",
    "Background checks or security training for staff"
  ]
}

[INPUT]
[RFP_RESPONSE_TEXT]

To adapt this template, first replace [RFP_RESPONSE_TEXT] with the actual text from the vendor. You can modify the [EXAMPLES] block to include risk scenarios that are more specific to your industry or procurement policies. For instance, you might add an example showing a MEDIUM risk tier for a vendor with strong technical controls but a poor financial history. The [OUTPUT_SCHEMA] can be extended to include fields like financial_risk_score or compliance_gaps if your downstream system requires them. Always test any changes to the examples against a golden dataset of known vendor responses to ensure the model's behavior remains consistent and accurate.

This prompt is not a standalone chat interaction; it is a classification and extraction module designed to sit inside a procurement or security review pipeline. The application layer should supply the RFP response text as [INPUT], the organization's risk taxonomy as [RISK_CATEGORIES], and the few-shot examples as [EXAMPLES]. The model returns a structured JSON object containing risk tier assignment, extracted evidence, and confidence scores. The surrounding harness must validate this output before it reaches a reviewer or a system of record.

Implement a strict JSON schema validator that checks for required fields (risk_tier, risk_indicators, evidence, confidence_score) and rejects malformed responses. On validation failure, retry once with the same prompt plus the validation error message appended as a repair instruction. If the retry also fails, log the raw output and escalate to a human review queue. For high-risk vendor assessments (e.g., those flagged as HIGH or CRITICAL), always route the final output to a human analyst for approval before updating the vendor record. Use a model with strong structured output support (GPT-4o with response_format or Claude 3.5 Sonnet with tool use) and set temperature to 0 to minimize variance in risk tier assignment.

Log every assessment with the prompt version hash, input RFP ID, model used, raw output, validation status, and final reviewer decision. This audit trail is essential for governance and for detecting example drift over time. Do not bypass human review for any vendor that handles sensitive data, critical infrastructure, or regulated services. The prompt is a triage accelerator, not a replacement for security judgment.