Category: Third-Party & Vendor
Vendor Risk Assessment
Also known as: VRA, Third-Party Risk Assessment, Supplier Risk Assessment
Simply put
A vendor risk assessment is the process an organization uses to identify and evaluate the risks that come from working with an outside vendor, supplier, or service provider. It typically looks at issues such as cybersecurity exposure and other risks a third-party relationship may introduce, so the organization can decide how to manage or reduce them. It is an evaluation activity, not a certification or a guarantee that a vendor is risk-free.
Formal definition
A vendor risk assessment is a systematized process for identifying, scoring, prioritizing, and monitoring the risks associated with a third-party vendor, supplier, or service provider relationship, commonly including the cyber risk posed by that relationship. It is generally conducted as part of a broader third-party risk management (TPRM) program and may draw on questionnaires, evidence review, and ongoing monitoring to inform onboarding and continuity decisions. As an assessment, it is distinct from an audit and from formal certification: it produces an internal evaluation of risk rather than an attestation against a defined standard. The specific scope, methodology, and frequency are organization-defined and vary by vendor criticality, data category, and applicable contractual or regulatory obligations; practitioners should align a given VRA with the framework or requirements relevant to their sector and jurisdiction and verify against current authoritative sources.
Why it matters
Organizations increasingly depend on outside vendors, suppliers, and service providers for functions that touch sensitive data, critical systems, and core operations. Each of these relationships can introduce risk that the organization does not directly control, including cybersecurity exposure arising from the vendor's own practices. A vendor risk assessment gives an organization a structured way to identify and evaluate that exposure before onboarding a vendor and throughout the relationship, so decisions about whether and how to engage are informed by an understanding of the risks involved rather than by assumption.
Who it's relevant to
Third-Party Risk and Procurement Teams
Teams responsible for onboarding and managing vendor relationships use vendor risk assessments to evaluate risk before engagement and to inform continuity decisions during the relationship, typically as part of a broader TPRM program.
Information Security Professionals
Security practitioners rely on the VRA process to identify and prioritize the cyber risk a third-party relationship may introduce, using questionnaires, evidence review, and ongoing monitoring to inform risk management decisions.
Compliance Officers
Compliance staff use vendor risk assessments to help demonstrate that third-party risks have been evaluated in line with applicable contractual or regulatory obligations, while keeping in mind that a VRA is an internal evaluation rather than a certification or attestation against a defined standard. The specific obligations vary by sector and jurisdiction and should be verified against current authoritative sources.
Auditors and Assessors
Those reviewing an organization's third-party risk practices examine how vendor risk assessments are scoped, conducted, scored, and monitored, and how the results feed onboarding and continuity decisions. They should note the distinction between a VRA as an evaluation activity and a formal audit or certification.
Inside VRA
Vendor Inventory and Scoping
A catalogue of third-party suppliers, service providers, and subprocessors, together with the nature of the goods or services they provide and the categories of data or systems they can access. Scoping determines which vendors warrant assessment and at what depth, since not every supplier presents equivalent risk.
Risk Tiering or Criticality Classification
A method for ranking vendors by the potential impact of their failure or compromise, typically weighing factors such as data sensitivity, access to critical systems, business dependency, and regulatory exposure. Higher-tier vendors generally receive more rigorous and more frequent review.
Due Diligence Evidence
Documentation gathered to evaluate a vendor's controls, which may include security questionnaires, independent audit or attestation reports (such as SOC 2 reports), certifications against voluntary standards (such as ISO/IEC 27001), policies, and prior incident history. Note that a certification demonstrates conformity to a standard's scope and is not itself proof of regulatory compliance.
Contractual and Legal Controls
Provisions that allocate responsibilities and obligations, which may include data protection terms, security requirements, breach notification commitments, audit rights, and, where personal data is involved, arrangements such as data processing agreements. The specific obligations depend on the applicable jurisdiction and the roles the parties occupy (for example controller versus processor under the GDPR).
Risk Analysis and Findings
The evaluation stage in which collected evidence is measured against the organization's control expectations and applicable obligations, producing identified gaps, residual risk ratings, and remediation or mitigation recommendations. This is an assessment activity and should not be confused with a formal audit or certification.
Ongoing Monitoring and Reassessment
Mechanisms for tracking a vendor's risk posture over time, since a point-in-time review can become outdated as services, subprocessors, threats, and regulations change. Reassessment cadence is generally aligned to the vendor's risk tier.
Common questions
Answers to the questions practitioners most commonly ask about VRA.
Is a vendor risk assessment the same as a vendor certification or audit?
No. A vendor risk assessment is an internal evaluation your organization performs to understand and manage the risk a third party may introduce, whereas a certification (such as ISO/IEC 27001) reflects an independent body's attestation against a defined standard, and an audit is a formal examination against specific criteria, often by an external party. A vendor's certification may serve as evidence within your assessment, but holding a certification does not by itself satisfy your obligation to assess that vendor. The scope, methodology, and party performing the work differ in each case, and they should not be treated as interchangeable.
Does a vendor risk assessment transfer or discharge our own compliance obligations?
Generally no. Engaging or assessing a vendor does not, in most cases, relieve your organization of accountability for the data or processes involved. For example, where a controller-processor relationship exists under data protection law, the controller typically retains its own responsibilities regardless of the assessment outcome. A vendor risk assessment is a tool to inform and evidence due diligence and ongoing oversight; it is not a mechanism for shifting legal responsibility. Application to a particular arrangement depends on the applicable framework, contract, and jurisdiction, and requires professional judgment.
When in the vendor relationship should a risk assessment be performed?
In most programs, an initial assessment is performed before onboarding or contracting, so that identified risks can inform the decision and any contractual safeguards. Because risk is not static, many organizations also reassess periodically and upon trigger events such as a change in the services provided, the data categories involved, the vendor's control environment, or a reported incident. The specific cadence often depends on the risk tier assigned to the vendor. Organizations should align timing with their own policies and any applicable regulatory or contractual requirements.
How can risk tiering help focus assessment effort?
Risk tiering is commonly used to allocate scrutiny in proportion to the risk a vendor presents, rather than applying identical depth to every supplier. Factors that organizations frequently consider include the sensitivity and category of data accessed, the criticality of the service to operations, the level of system access granted, and any applicable regulatory exposure. Higher-tier vendors may warrant more detailed evidence review and more frequent reassessment, while lower-tier vendors may be handled through a lighter process. The specific tiering criteria and thresholds are set by each organization and should reflect its risk appetite and obligations.
What types of evidence are typically requested from a vendor during an assessment?
Evidence requested often includes completed security or privacy questionnaires, independent reports or attestations (such as SOC 2 reports or certifications where available), relevant policies, and documentation of controls addressing areas like access management, encryption, incident response, and subprocessor use. Where personal data is involved, organizations may also review data processing terms and information about international data transfers. The value of any evidence depends on its scope, currency, and relevance to the services in question, so validity dates and applicability should be checked rather than assumed.
How should assessment findings be tracked and followed up?
Findings are commonly documented so that identified gaps can be assigned an owner, a remediation plan, and a timeline proportionate to their severity. Some organizations accept residual risk through a formal exception or acceptance process where remediation is not feasible, and record that decision. Ongoing monitoring and reassessment help confirm that agreed actions are completed and that the vendor's risk profile has not materially changed. Specific tracking mechanisms, escalation paths, and documentation retention should follow the organization's own governance policies and any applicable requirements.
Common misconceptions
A vendor that holds a certification such as ISO/IEC 27001 or produces a SOC 2 report is therefore compliant with the regulations that apply to my organization.
Certifications and attestations relate to voluntary or contractual standards and cover a defined scope; they demonstrate conformity to that standard, not compliance with binding law such as the GDPR or HIPAA. The assessing organization generally remains responsible for confirming that a vendor's controls actually address its own regulatory obligations, and the scope of any report should be checked rather than assumed.
A vendor risk assessment is a one-time exercise completed before onboarding.
A single assessment captures a point in time. Because a vendor's services, subprocessors, threat environment, and applicable requirements can change, most programs treat assessment as a recurring activity with monitoring and reassessment, generally tied to how critical the vendor is.
Outsourcing a function to a vendor transfers the associated compliance responsibility to that vendor.
Engaging a third party generally does not extinguish the engaging organization's own obligations. Depending on the jurisdiction and the roles involved, accountability may remain with the organization even where day-to-day processing is performed by a supplier; the precise allocation is fact-specific and depends on applicable law and contract.
Best practices
Maintain a current vendor inventory and apply a documented risk-tiering method so that assessment depth and frequency are proportionate to each vendor's criticality and data access.
Verify the scope and validity period of any certification or attestation report a vendor provides, rather than treating it as blanket assurance, and map the evidence to your own control and regulatory expectations.
Keep contractual controls aligned with the roles and jurisdictions involved, including data protection terms, breach notification, and audit or reassessment rights where appropriate, and confirm the specifics against current authoritative requirements.
Distinguish the assessment from an audit or certification in your documentation, recording identified gaps, residual risk, and agreed remediation with owners and timelines.
Establish ongoing monitoring and scheduled reassessment, triggered both by tier-based cadence and by material changes such as new subprocessors, service changes, or incidents.
Involve appropriate professional judgment (legal, privacy, and security functions) when applying findings to specific circumstances, since obligations are fact-specific and both regulations and standards are periodically revised.
