Vendor Risk Assessment Template

In plain language: Records the vendor's full legal name, corporate registration, primary contact, and the exact nature and scope of the services they will provide.

Common mistake: Describing services in general terms like 'IT support' instead of specifying which systems, data types, and access levels are involved — making risk tier classification impossible.

In plain language: Assigns the vendor to a risk tier (Critical, High, Medium, or Low) based on the sensitivity of data accessed, criticality to operations, and regulatory exposure.

Common mistake: Assigning risk tiers subjectively without a scoring rubric — two assessors then classify the same vendor differently, undermining the consistency regulators expect to see.

In plain language: Documents the vendor's security certifications, access controls, encryption standards, vulnerability management practices, and penetration testing cadence.

Common mistake: Accepting a vendor's self-attestation on security controls without requesting the underlying audit report or certificate. A claim of 'SOC 2 compliance' is meaningless without reviewing the actual Type II report.

In plain language: Confirms the vendor's compliance with applicable data protection laws and records any certifications, DPA execution, cross-border transfer mechanisms, and breach notification timelines.

Common mistake: Omitting the breach notification timeline from the assessment, then discovering during an incident that the vendor's contract has no defined notification window and their default is 30 days — far too slow under GDPR and HIPAA.

In plain language: Captures the vendor's documented BCP/DRP, RTO and RPO commitments, geographic redundancy, and last test date for recovery procedures.

Common mistake: Recording that a BCP exists without asking for the last test date or test results — a plan that has never been tested provides no real assurance of recovery capability.

In plain language: Documents evidence of the vendor's financial health — audited financials, credit ratings, insurance certificates, and any known insolvency or litigation risk — to assess concentration and continuity risk.

Common mistake: Skipping financial due diligence for vendors providing non-critical services, then discovering a sole-source supplier has entered insolvency — causing an unplanned operational disruption with no qualified backup.

In plain language: Requires the vendor to disclose all subcontractors and sub-processors who will touch your data or contribute to service delivery, and confirm that the same security standards apply to them.

Common mistake: Not requiring prior notice of subcontractor changes — a vendor quietly switches to a sub-processor in a non-adequate country, creating an unlawful cross-border transfer the company only discovers during an audit.

In plain language: Defines what constitutes a security incident, the notification timeline, the communication channel, and the vendor's obligations to cooperate in investigation and remediation.

Common mistake: Defining 'incident' so narrowly (e.g., only confirmed breaches) that suspected incidents and near-misses are never reported — leaving the company blind to warning signs before a major event occurs.

In plain language: Presents the overall risk score derived from the assessment, identifies any control gaps, and records the vendor's commitments to close those gaps by specified deadlines before or after onboarding.

Common mistake: Approving vendor onboarding before remediation deadlines are met and without a documented conditional approval process — removing all leverage to actually compel the vendor to close the identified gaps.

In plain language: Records the authorized signatories from both parties who certify the accuracy of the assessment, and commits both sides to the next reassessment date and the process for material changes.

Common mistake: Treating the assessment as a one-time intake form with no review schedule — vendors assessed at onboarding are never reassessed, even after major changes to their infrastructure, ownership, or regulatory exposure.

A vendor risk assessment is a structured process and document used to evaluate the risks a third-party supplier or service provider poses to your organization before or during a business relationship. It covers information security, data privacy compliance, financial stability, business continuity, and operational controls. The completed assessment creates a documented risk record that supports vendor approval decisions, contractual obligations, and regulatory audits.

Complete a vendor risk assessment before onboarding any new vendor who will access your data, systems, or critical operations. Reassess existing vendors on a schedule tied to their risk tier — annually for high-risk vendors, every six months for critical ones — and whenever a vendor undergoes a material change such as an acquisition, a significant change to their service scope, or a reported security incident.

Responsibility typically falls to a combination of procurement, IT security, legal, and compliance teams, depending on the organization's size and structure. In smaller organizations, the owner or operations manager often conducts the assessment with input from an IT advisor. In regulated industries, a dedicated third-party risk management function typically owns the process. Both parties — the assessing company and the vendor — must certify the assessment at completion.

A vendor security questionnaire is a list of questions a vendor self-completes to describe their security controls — it is an input to the risk assessment process, not the assessment itself. A vendor risk assessment is the broader document that incorporates the questionnaire responses alongside independent verification, financial due diligence, compliance documentation, and a risk scoring summary. The assessment results in a formal approval decision and a documented remediation plan.

In regulated industries, documented third-party risk assessments are typically required by law or regulation. HIPAA requires covered entities to assess the risks posed by business associates. GDPR requires controllers to verify that processors provide sufficient guarantees. PCI DSS requires service provider due diligence. Financial services regulators in the US (OCC, FFIEC), UK (FCA), and EU (EBA) all publish third-party risk management guidance that effectively mandates documented assessments for material vendor relationships.

Most organizations use a four-tier system: Critical (vendors providing essential services or accessing the most sensitive data, such as core banking platforms or cloud infrastructure), High (vendors with significant data access or operational impact), Medium (vendors with limited data access and manageable service impact), and Low (vendors with no data access and minimal operational exposure, such as stationery suppliers). The tier determines assessment frequency, control requirements, and escalation procedures.

A failed assessment does not automatically disqualify a vendor — it triggers a remediation process. Critical or unacceptable gaps should be documented and the vendor should be given a conditional approval with specific remediation deadlines. If gaps are not closed by those deadlines, the engagement should not proceed or should be terminated. In some cases, compensating controls on your side (additional encryption, network segmentation, or contractual indemnification) can reduce residual risk to an acceptable level.

Under GDPR, any vendor who processes personal data on your behalf is a data processor, and you — as the data controller — are legally required to ensure they provide sufficient guarantees of appropriate technical and organizational measures. This means conducting documented due diligence before engagement, executing a Data Processing Agreement, verifying cross-border transfer mechanisms, and confirming breach notification timelines of no more than 72 hours. Failure to conduct this due diligence exposes you to regulatory action, even if the breach originated with the vendor.

Review frequency should be tied to risk tier: critical vendors every six months, high-risk vendors annually, medium-risk vendors every two years, and low-risk vendors every three years or upon material change. Trigger an immediate out-of-cycle review whenever a vendor reports a security incident, undergoes a merger or acquisition, changes their subprocessor arrangements, or enters a new regulatory environment.