Vendor Security Assessment: How to Evaluate Third-Party Risk

Your security posture is only as strong as your weakest vendor. The 2020 SolarWinds attack compromised 18,000 organizations through a single software provider. In 2023, the MOVEit breach cascaded across hundreds of companies that relied on a file transfer utility. Third-party risk is not a theoretical concern — it is one of the most common root causes of significant data breaches.

A vendor security assessment program lets you understand the risk you are accepting before signing a contract, and monitor it continuously afterward.

Building Your Vendor Inventory

You cannot manage risk you have not identified. Start by cataloguing every external vendor that has access to your systems, your data, or your infrastructure. Include:

SaaS applications used by employees
Cloud infrastructure providers
Software components and open-source libraries your product depends on
Professional services providers with system access (IT consultants, managed security providers)
Payment and financial service providers

For each vendor, capture at minimum: vendor name, service provided, data types they access, criticality to operations (if this vendor failed or was breached, what would be the impact), and your primary contact.

Classify vendors into tiers based on the risk they represent:

Tier 1 (Critical): Vendors with access to sensitive personal data, financial data, or production systems. A breach at this vendor could directly compromise your customers. Examples: cloud infrastructure, identity providers, payment processors, CRM with customer data.
Tier 2 (Significant): Vendors with indirect access or access to non-sensitive business data. A breach could cause business disruption but not direct customer data exposure.
Tier 3 (Low): Vendors with no data access and low operational criticality. Marketing analytics, project management tools with no sensitive data.

Apply the most rigorous assessment process to Tier 1 vendors. Tier 3 may only require a lightweight review of their privacy policy and terms of service.

Security Questionnaire Design

A security questionnaire gives vendors an opportunity to self-attest to their security controls. Standardized questionnaire frameworks save time for both sides — your vendor has likely already completed a similar questionnaire for other customers.

The most widely used framework is the SIG (Standardized Information Gathering) questionnaire from Shared Assessments. Other options:

CAIQ (Consensus Assessments Initiative Questionnaire) from Cloud Security Alliance — specifically designed for cloud providers, maps to CSA CCM controls
VSAQ (Vendor Security Assessment Questionnaire) from Google — open-source, lightweight
Custom questionnaires aligned to your specific controls or regulatory requirements

For Tier 1 vendors, a full SIG or CAIQ is appropriate. For Tier 2, a shortened questionnaire covering the highest-risk areas suffices.

Core areas every vendor questionnaire should cover:

Data Security

What data types do you process on our behalf?
How is data encrypted at rest and in transit?
Where is data stored geographically?
What is your data retention and deletion policy?

Access Controls

How is access to systems containing our data managed?
Is MFA enforced for all employee access?
How are employee access rights reviewed?
What is your offboarding process for employee departures?

Incident Response

Do you have a documented incident response plan?
What is your timeline for notifying customers of a security incident?
Describe the most significant security incident you have experienced in the past three years and how it was handled.

Third-Party Subprocessors

Which third-party subprocessors have access to data you process on our behalf?
How are subprocessors assessed for security?

Certifications and Audits

Do you hold any security certifications (SOC 2, ISO 27001, PCI DSS)?
Can you share your most recent audit report or certification?
When was your last penetration test, and can you share results or a summary?

Business Continuity

What is your documented RTO and RPO?
When was your business continuity plan last tested?
Do you have redundant data centers or availability zones?

Evidence Review: Beyond Self-Attestation

Questionnaire responses are self-reported and unverified. For Tier 1 vendors, require documentary evidence alongside questionnaire responses.

Acceptable evidence includes:

SOC 2 Type 2 report: The gold standard for SaaS vendors. Review the auditor's opinion, the observation period (ideally within the past 12 months), and the exceptions section. Exceptions are not automatically disqualifying, but understand what they are and whether they affect controls relevant to your use case.
ISO 27001 certificate: Verify it is current and the certificate scope covers the services you use. A certificate scoped to "corporate office operations" that excludes the data center is not relevant.
PCI DSS Attestation of Compliance (AOC): For payment-related vendors.
Penetration test executive summary: Should be from a named third-party firm, dated within 12–18 months, and show that critical findings were remediated.
CAIQ documentation: Cloud providers completing the CSA CAIQ provide detailed control mappings.

Do not accept screenshots of a dashboard or unformatted text as evidence of compliance. If a vendor cannot produce a third-party attestation, that is itself a risk indicator.

Review the report, not just the fact of its existence. A SOC 2 Type 1 report is much weaker assurance than a Type 2. A Type 2 covering only a three-month observation period is weaker than one covering twelve months. An audit with fifteen exceptions across access controls and monitoring is concerning regardless of whether the auditor issued a qualified opinion.

Contract Requirements

Security requirements should be in the contract, not just in pre-sales conversations. For Tier 1 and Tier 2 vendors, your agreements should include:

Data Processing Agreement (DPA): Required under GDPR and many other privacy regulations. Specifies what data the vendor processes, for what purpose, and the vendor's security obligations.
Breach notification timeline: Specify how quickly the vendor must notify you of a breach affecting your data. 48–72 hours is a reasonable requirement; some regulations require you to notify regulators within 72 hours, so you need time to investigate after receiving notice.
Right to audit: Retain the right to audit the vendor's security controls, or require them to provide updated third-party audit reports annually.
Subprocessor approval: Require the vendor to notify you before engaging new subprocessors that will have access to your data, and give you the right to object.
Data deletion: Require certified deletion of your data within a defined period upon contract termination.

Ongoing Monitoring

Third-party risk assessment is not a one-time activity. Vendors change — they get acquired, they launch new products that change their attack surface, they suffer breaches they do not immediately disclose. Continuous monitoring is essential.

Annual reassessment: Require Tier 1 vendors to complete a refreshed questionnaire and provide updated audit evidence annually. For SOC 2-certified vendors, the annual report cycle aligns naturally with this.

Breach monitoring: Subscribe to data breach notification services or threat intelligence feeds that alert you when a vendor appears in breach databases or dark web dumps. Monitor vendor security announcements and public breach disclosures.

Security posture monitoring: External scanning tools can continuously assess a vendor's public-facing security posture — TLS configuration, open ports, exposed services, domain health. These do not replace audit evidence but can surface changes in posture between assessments.

SLA and incident tracking: Track how vendors perform against their stated RTOs and breach notification timelines. A vendor that has had three incidents in two years without effective remediation is a pattern worth escalating.

Communicating Risk to Leadership

Vendor risk findings need to reach decision-makers. Build a simple dashboard that shows:

Number of Tier 1 vendors with current audit reports
Number of Tier 1 vendors overdue for reassessment
Open high-risk findings from vendor assessments
Vendors currently under review for potential issues

When a high-risk finding is identified — a Tier 1 vendor cannot produce a SOC 2 report, or their penetration test reveals critical unpatched vulnerabilities — escalate to leadership with a clear recommendation: require remediation with a defined timeline, impose compensating controls, or replace the vendor.