Vendor Risk Assessment Template: What to Ask Vendors Before You Sign

TL;DR

• The Change Healthcare breach (Feb 2024, 192.7M records) happened because a Citrix portal lacked MFA — a single questionnaire item that would have caught it
• A vendor risk assessment is not the questionnaire alone; it’s the questionnaire plus the evidence plus the residual-risk decision
• SIG, SIG Lite, and CAIQ cover most of what you need for cyber and cloud — but they don’t cover financial health, fourth parties, or AI risk by default
• The 2023 Interagency Guidance on Third-Party Relationships made the lifecycle obligation explicit: assess at onboarding, reassess on cadence, reassess on trigger
• Eight red flags should stop a contract before signature — including the one that took down Change Healthcare

UnitedHealth’s Change Healthcare unit went dark on February 21, 2024. ALPHV/BlackCat ransomware locked up systems that processed roughly a third of U.S. medical claims. Pharmacies couldn’t fill prescriptions. Hospitals stopped getting paid. The breach reached 192.7 million people — the largest healthcare data breach in U.S. history.

The root cause? Compromised credentials on a Citrix remote access portal that didn’t require multi-factor authentication. UHG had acquired Change Healthcare in October 2022 and, per congressional testimony, hadn’t updated Change’s security stack to UHG’s own standards in the 16 months between acquisition and breach.

A baseline vendor risk assessment with one functioning question — “Is MFA enforced on all administrative and remote access?” — would have caught it. The post-breach senate scrutiny focused heavily on what cybersecurity due diligence UHG performed before and after the acquisition. The answer was: not enough.

This is what a vendor risk assessment is actually for. Not paperwork. Not vendor management theater. The single document standing between your firm and the breach you’ll be asked to defend in front of regulators, customers, and a congressional committee.

What a Vendor Risk Assessment Is For

A vendor risk assessment has two jobs. The first is decision support: should we sign this vendor, and on what terms? The second is defensibility: when something goes wrong, can we show we asked the right questions, demanded the right evidence, and reached a defensible decision based on what we knew at the time?

Both jobs require the same inputs. A questionnaire. Supporting evidence. A scoring framework. A residual-risk rating. A documented decision.

What it is not:

• It is not a security review of the vendor’s product. (That’s a separate exercise.)
• It is not a substitute for a contract. (Both are required.)
• It is not a one-time event. (Reassessment is part of the lifecycle.)
• It is not the whole vendor risk management program. (It’s one stage in a five-stage lifecycle.)

The Eight Domains a Template Should Cover

A defensible vendor risk assessment template covers eight domains. The depth in each scales with the vendor’s risk tier — a SaaS vendor handling production customer data needs more scrutiny in domains 2, 3, and 6 than a marketing analytics vendor processing aggregated data.

The depth of questions in each domain should match what the vendor will actually do. A printer ink supplier needs domain 1 and 8 only. A core banking provider needs every question in every domain plus a financial-health appendix.

Domain 1: Company and Ownership

Most assessments skip this domain. They shouldn’t. The two largest vendor failures of the last three years — Synapse Financial Technologies’ bankruptcy and the broader BaaS-fintech meltdown — were financial-health failures, not cybersecurity failures. By the time the security questionnaire would have flagged anything, customer funds were already missing.

Critical questions:

• Provide audited financial statements for the last three years (or equivalent for private companies)
• Disclose any going-concern qualifications, restatements, or auditor changes in the last 36 months
• Disclose any material litigation, regulatory actions, or settlements (with copies of consent orders)
• Provide the corporate structure, including all parent and subsidiary entities
• Confirm screening against OFAC, EU consolidated sanctions, and UK HMT lists for all UBOs > 25%
• Disclose any operations or personnel located in sanctioned jurisdictions

Evidence to demand: Audited financials, certificate of good standing, sanctions screening report, ownership disclosure.

Red flag: Going-concern opinion, material litigation not disclosed, or refusal to provide ownership beyond the operating entity.

Domain 2: Information Security

This is where most TPRM programs concentrate, for good reason. The Change Healthcare, Snowflake (2024 UNC5537 campaign), and SolarWinds compromises were all preventable security failures. The questions you need to ask are not exotic.

Critical questions:

• Is MFA required for all administrative access, remote access, and customer-facing portals? (No exceptions.)
• What encryption is applied to data at rest and in transit? (AES-256 / TLS 1.2+ minimum.)
• What vulnerability scanning and patching cadence is in place? (Critical patches within 7 days; high within 30.)
• When was the last independent penetration test, and is the executive summary available?
• How are privileged credentials managed? (Vaulting, rotation, just-in-time access.)
• What logging and monitoring is in place, and how long are logs retained?
• Is there a documented Secure SDLC, and is code reviewed before production deployment?
• How are workstations managed for personnel with production access? (EDR, full disk encryption, OS patching.)

Evidence to demand: SOC 2 Type II (current, clean opinion), penetration test executive summary (within 12 months), ISO 27001 certificate if claimed, SOC 2 readiness assessment results if certification is in progress.

Red flag: No MFA on admin/remote access, no current pen test, no SOC 2 or equivalent attestation, refusal to share the SOC 2 executive summary even under NDA.

Domain 3: Privacy and Data Handling

Privacy questions need to map to your specific regulatory obligations. A vendor handling EU resident data triggers GDPR; a vendor processing California resident data triggers CCPA/CPRA; healthcare vendors trigger HIPAA; financial advisors trigger Reg S-P and the SEC’s amendments effective 2024.

Critical questions:

• What categories of personal data will the vendor process on your behalf?
• Where physically will the data be stored? (Country, region, specific data center if relevant.)
• How long is data retained? Can the vendor commit to deletion / return on termination within a defined window?
• Will the data be used for any purpose other than providing the contracted service? (Training the vendor’s models, benchmarking, marketing — all need explicit answers.)
• Can the vendor provide a current list of sub-processors that will access the data?
• Will the vendor commit to giving advance notice of new sub-processors with right to object?

Evidence to demand: Data Processing Agreement (DPA), sub-processor list, data flow diagram showing where data physically resides.

Red flag: Vague answers on data use (“we may use it to improve the service”), refusal to disclose sub-processors, no DPA template available.

Domain 4: Business Continuity and Disaster Recovery

The CrowdStrike Falcon outage on July 19, 2024 — a single defective sensor update that grounded airlines, took down hospitals, and disrupted financial services for days — was a vendor BCP/DR failure. Customers had no useful BCP plan because they had no alternative monitoring stack and no playbook for “what if our endpoint security vendor is the source of the outage.”

Critical questions:

• What is the documented Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for the contracted service?
• When was the BCP/DR plan last tested? Provide the test report and any remediation actions.
• What dependencies does the service have on other vendors, cloud regions, or single points of failure?
• What is the vendor’s communication plan during a major incident?
• If the vendor’s primary region fails, what is the failover process and how long does it take?

Evidence to demand: BCP/DR test report from the last 12 months, dependency map, communication runbook.

Red flag: No DR test in 18+ months, undocumented RTO/RPO, single-region deployment for a critical service.

Domain 5: Compliance and Certifications

What you need depends on the service. Match the request to the vendor’s role.

Evidence to demand: Current certificates and attestation reports, not marketing PDFs claiming compliance.

Red flag: “Compliance with [framework]” claimed without an independent attestation; SOC 2 Type I when Type II is available; expired certificates.

Domain 6: Subcontractors and Fourth Parties

This is where most TPRM programs go blind. Your vendor outsources to their vendors. Their vendors outsource to theirs. By the time customer data reaches the actual processor, you have zero visibility into what’s happening with it.

Critical questions:

• Provide the current list of sub-processors with the country of operation and the categories of data each one accesses
• Will the vendor commit to giving advance notice of new sub-processors? (Standard is 30 days; right to object should be reserved.)
• What due diligence does the vendor perform on its own sub-processors? (Frequency, framework, evidence requirements.)
• What contractual flow-down provisions exist between the vendor and its sub-processors?

Evidence to demand: Sub-processor list, vendor’s own TPRM policy, sample sub-processor due diligence report.

Red flag: No sub-processor list, no flow-down provisions, no documented sub-processor due diligence process.

Domain 7: Incident Response

The point of the IR section is not to admire the vendor’s runbook. It’s to confirm the vendor has the operational discipline to detect, contain, and tell you in time.

Critical questions:

• What is the committed incident notification window? (24 hours is the new standard for material incidents; 72 hours is acceptable for moderate.)
• What constitutes a “material” or “notifiable” incident under the contract?
• Who is the contractual notification contact, and what is the backup channel?
• What incident response framework does the vendor follow? (NIST SP 800-61 is the U.S. baseline.)
• Will the vendor commit to providing root-cause analysis within 30 days of containment?

Evidence to demand: IR plan, notification template, breach disclosure history (some vendors will share post-mortems for past incidents under NDA).

Red flag: Notification window > 72 hours, vague “material” definition, no commitment to RCA delivery, history of breach disclosures dragging out for weeks.

Domain 8: Contract and Exit

The contract is where the assessment becomes enforceable. Without contract teeth, the questionnaire is performative.

Critical contract provisions:

• Audit rights — your right to audit the vendor’s controls, or to receive their SOC 2 Type II annually
• Right to examination assistance — for regulated entities, the right for your regulator to examine the vendor
• Notification obligations — incident notification within X hours, sub-processor changes with X days notice
• Data handling — purpose limitation, retention limits, return/destruction on termination
• Termination for cause — defined triggers (security breach, regulatory action, financial distress, repeated SLA failures)
• Termination assistance — vendor’s obligation to support transition for X months post-termination
• Surviving obligations — confidentiality, data return, indemnification surviving termination
• Cyber insurance — minimum limits stated in the contract (typically $5M+ per occurrence for material vendors)

Red flag: Vendor refuses any of audit rights, examination assistance, or termination-for-cause triggers; cyber insurance limits below your exposure.

Scoring: Inherent and Residual Ratings

Two scores. Don’t overcomplicate it.

Inherent risk — what the vendor will do for you, before considering their controls. Calculated from:

The aggregate inherent score drives vendor tier — Tier 1 (Critical) for top-quartile inherent scores; Tier 2 (Elevated) for middle-half; Tier 3 (Standard) for low scores.

Residual risk — what remains after evaluating their controls. Score each of the eight domains based on the questionnaire responses and supporting evidence, then aggregate. The decision rule:

• Residual = Low → Approve, standard contract
• Residual = Moderate → Approve with specific contract additions (e.g., heightened notification windows, additional audit rights)
• Residual = High → Either remediate before signing (vendor commits to specific control improvements) or don’t sign
• Residual = Critical → Don’t sign

SIG, SIG Lite, and CAIQ — When to Use Which

Don’t reinvent the questionnaire. Use industry standards and tailor them.

The SIG and CAIQ are paid (SIG) or freely available (CAIQ) — the value is the standardization. Vendors that field many requests will have completed responses ready, accelerating your assessment.

What SIG and CAIQ don’t cover well: financial health, fourth-party visibility, and AI-specific risks. You need to layer your own questions on top — see our third-party AI vendor risk assessment for the AI-specific additions.

Eight Red Flags That Should Kill a Contract

These are dealbreakers, not negotiating positions. If a vendor refuses to fix them, walk away.

1. No MFA on administrative or remote access — this is what enabled Change Healthcare
2. No current SOC 2 Type II (or industry equivalent) when one is standard for the service category
3. Refusal to provide audit rights or examination assistance for regulated customers
4. Incident notification window longer than 72 hours, or vague definition of “material”
5. No sub-processor list or refusal to commit to advance notice of changes
6. Refusal to commit to data return / certified destruction on termination
7. Financial distress signals — going-concern opinion, missed payroll, security/engineering layoffs
8. Operations or ownership in sanctioned jurisdictions without disclosure

The 2023 Interagency Guidance Context

For U.S. banks, the 2023 Interagency Guidance on Third-Party Relationships (OCC Bulletin 2023-17, June 6, 2023) made the lifecycle expectation explicit: planning → due diligence → contract negotiation → ongoing monitoring → termination. The risk assessment isn’t a one-time gate — it’s the foundation for ongoing monitoring obligations that follow.

Three things examiners are now looking for that they weren’t five years ago:

1. Tiered approach — different scrutiny for different criticality. The same questionnaire for the cloud provider and the landscaper is a finding.
2. Documented risk-based decision — not just “we did the questionnaire” but “here’s the residual rating, here’s why we accepted it, here’s what we required in contract.”
3. Reassessment cadence — annual for Tier 1, with event-triggered reviews on top (vendor breach, ownership change, regulatory action against the vendor).

So What?

A vendor risk assessment is the document that decides whether the next major breach is yours to defend. The Change Healthcare lesson is the right one to internalize: a single missing control — MFA — destroyed an enterprise’s reputation, exposed 192.7M people, and triggered congressional scrutiny that’s still ongoing. The vendor risk assessment that asks the question, demands the evidence, and refuses the contract without the answer is what stands between your firm and that outcome.

Build the template once. Tier vendors so the depth scales with the risk. Demand evidence — never accept self-attestation alone. Document the decision and the residual rating. Reassess on cadence and on trigger.

If a vendor won’t answer the eight critical questions, won’t provide the evidence, or won’t accept the contract terms — the answer is no. The cost of walking away from a vendor is bounded. The cost of the breach you’re about to inherit is not.

The Third-Party Risk Management (TPRM) Kit includes a vendor risk assessment template covering all eight domains, the SIG/CAIQ mapping, scoring rubric, contract clause library, and ongoing monitoring tracker — everything you need to run a defensible TPRM program from day one.