Security2026-04-0219 min read

Third-Party Vendor Security Assessment Template

Q: How do you assess a vendor's security posture?

Start with three layers of assessment. First, request compliance certifications (SOC 2 Type II, ISO 27001, PCI DSS) as baseline evidence. Second, send a security questionnaire covering encryption, access controls, incident response, data handling, and employee security practices. Third, perform technical validation: review their SSL/TLS configuration, check for known vulnerabilities in their public-facing infrastructure, verify their data encryption claims, and request penetration test reports. For critical vendors, consider a right-to-audit clause that allows you to conduct or commission your own security assessment of their environment.

Q: How often should vendor security be reassessed?

Reassessment frequency should be risk-based. Critical vendors (those with access to sensitive data, production systems, or customer PII) should be reassessed annually with continuous monitoring of their security posture between assessments. High-risk vendors should be reassessed every 12 to 18 months. Medium and low-risk vendors can be reassessed every 24 months. However, any vendor should be immediately reassessed after a reported breach, a significant change in their service scope, a change in their ownership or leadership, or when they fail to maintain required certifications.

Every vendor you onboard extends your attack surface. Their security posture becomes your security posture the moment they touch your data, connect to your network, or process your customers' information. The SolarWinds breach, the Kaseya ransomware attack, the MOVEit exploitation — all of these were third-party vendor compromises that cascaded to thousands of downstream organizations.

A 2025 study by SecurityScorecard found that 63% of data breaches can be traced back to third-party vendors. Despite this, most organizations assess vendor security with a checkbox questionnaire that was last updated in 2019 and nobody reads the responses. This guide provides a practical, current assessment framework that helps you evaluate real vendor risk — not just collect compliance paperwork.

Why Vendor Security Matters More Than Ever

The average enterprise uses over 1,000 SaaS applications (Productiv, 2025). Each one is a vendor with access to some subset of your data. Many of those vendors use their own subprocessors, creating a supply chain three or four layers deep. When a breach happens at any layer, the data that is exposed is yours.

The regulatory environment has caught up to this reality. SOC 2 requires vendor management controls. ISO 27001 mandates supplier relationship security. GDPR holds data controllers liable for their processors. PCI DSS requires that service providers maintain compliance. HIPAA extends breach notification requirements to business associates. If your vendor is breached, you are responsible for the consequences.

The challenge is practical: how do you assess hundreds of vendors without drowning in questionnaires? The answer is risk-based tiering. Not every vendor needs the same level of scrutiny. A marketing analytics tool that sees anonymized traffic data does not need the same assessment as a payroll processor that handles Social Security numbers.

Building a Vendor Risk Assessment Framework

Step 1: Vendor Inventory

Before you can assess vendor risk, you need to know who your vendors are. This sounds obvious, but most organizations cannot produce a complete list of third-party services that have access to their data. Build a vendor inventory that includes:

Vendor name and primary contact
Service provided and business justification
Type of data accessed (PII, financial, IP, operational)
Volume of data processed
Integration method (API, file transfer, direct database access, manual)
Contract start date, renewal date, and termination notice period
Subprocessors the vendor uses (and their locations)

Step 2: Risk Tiering

Assign each vendor to a risk tier based on the sensitivity of data they access and the criticality of the service they provide:

Tier	Criteria	Assessment Depth	Reassessment
Critical	Access to PII, financial data, or production systems; business-critical service	Full assessment + penetration test review + on-site audit (if applicable)	Annually
High	Access to internal data, integration with corporate systems	Full questionnaire + certification review + technical validation	Every 12-18 months
Medium	Limited data access, non-critical service	Abbreviated questionnaire + certification review	Every 24 months
Low	No data access, no system integration	Basic due diligence (public info, reputation check)	At renewal

Step 3: Assessment Process

Pre-assessment research: Review the vendor's public security page, SOC 2 report availability, known breach history, and security ratings from platforms like SecurityScorecard or BitSight
Questionnaire: Send the risk-tiered questionnaire (detailed below) with a defined response deadline
Documentation review: Evaluate SOC 2 Type II reports, ISO 27001 certificates, penetration test summaries, and insurance certificates
Technical validation: For critical and high-tier vendors, verify claims with technical testing (SSL configuration, public vulnerability scans, API security review)
Risk rating: Score the vendor's responses and assign a risk rating with identified gaps and remediation requirements
Decision: Accept the risk, require remediation before proceeding, or reject the vendor

Security Questionnaire Template

The following questionnaire covers the essential security domains for a thorough vendor assessment. Adjust the depth based on the vendor's risk tier.

1. Organizational Security

Do you have a dedicated security team or officer? How many people?
What security certifications do you hold? (SOC 2 Type II, ISO 27001, PCI DSS, HITRUST)
When was your last external security audit? Can you share the report or summary of findings?
Do you carry cyber liability insurance? What is the coverage amount?
Do you have a formal information security policy? When was it last updated?

2. Access Control and Authentication

How do you enforce authentication for access to customer data? Is MFA required?
Do you support SSO integration (SAML, OIDC) for customer-facing applications?
How do you manage privileged access? Do you use a PAM solution?
How are employee accounts deprovisioned upon termination? What is the SLA for access revocation?
Do you perform regular access reviews? How frequently?

3. Data Protection

How is customer data encrypted at rest? What algorithm and key length?
How is data encrypted in transit? Do you enforce TLS 1.2 or higher?
Who manages encryption keys? Do you use a hardware security module (HSM)?
Where is customer data stored geographically? Can data residency requirements be accommodated?
What is your data retention policy? How is data deleted when the relationship ends?
Do you use customer data for any purpose beyond delivering the contracted service (analytics, training, marketing)?

4. Incident Response

Do you have a documented incident response plan? When was it last tested?
What is your breach notification timeline? (GDPR requires 72 hours; best practice is 24-48 hours)
Have you experienced a data breach in the past 3 years? If yes, what was the outcome and what changes were made?
Do you have a dedicated incident response team or do you use a third-party retainer?

5. Infrastructure Security

Where is your infrastructure hosted? (AWS, Azure, GCP, on-premises, hybrid)
How do you manage vulnerability scanning and patching? What is your SLA for critical patches?
Do you perform regular penetration testing? How frequently? Can you share a summary of the most recent test?
Is your network segmented to isolate customer data from other systems?
Do you use a WAF, IDS/IPS, or other perimeter security controls?

6. Employee Security

Do you perform background checks on employees with access to customer data?
How frequently do employees receive security awareness training?
What is your process for revoking access when an employee leaves?
Do employees sign confidentiality and acceptable use agreements?

When sharing API keys, integration credentials, or configuration data with vendors during onboarding, never use email or messaging platforms. Use zero-knowledge encrypted sharing tools that create self-destructing links. The credential should not persist in any communication channel.

Share Vendor Credentials Securely

When exchanging API keys and integration credentials with vendors, use SecureBin's zero-knowledge encrypted links. One view, then the data is permanently deleted.

Create Encrypted Link →

Evaluating Vendor Encryption Practices

Encryption is the single most important technical control to evaluate in a vendor assessment. A vendor that does encryption well is likely doing many other things well. A vendor that gets encryption wrong is probably cutting corners elsewhere too.

What to Look For

Area	Acceptable	Red Flag
Data at rest	AES-256, customer-managed keys option	No encryption, or vendor-only key management with no rotation
Data in transit	TLS 1.2+, HSTS enabled, strong cipher suites	TLS 1.0/1.1 supported, weak ciphers, no HSTS
Key management	HSM-backed, automatic rotation, separation of duties	Keys stored in application code, no rotation, single admin
Backup encryption	Encrypted backups with separate key from production	Unencrypted backups, same key as production data
API security	OAuth 2.0 / API keys with rotation, rate limiting	Basic auth over HTTP, no rate limiting, no key rotation

Technical Validation

Do not take the vendor's word for their encryption practices. Verify what you can:

Use an SSL checker to verify their TLS configuration, certificate validity, and cipher suites
Check their DNS configuration for DNSSEC, SPF, DKIM, and DMARC records
Review their API documentation for authentication mechanisms and security headers
Request their most recent penetration test summary — specifically the encryption-related findings
If they claim SOC 2 compliance, request the full report (not just the opinion letter) and review the encryption-related controls

Contract Security Requirements

The vendor assessment identifies risks. The contract is where you enforce controls. Every vendor contract should include these security clauses:

Essential Contract Clauses

Data processing terms: Define exactly what data the vendor will access, how it will be processed, and for what purposes. Prohibit use of customer data for any purpose beyond service delivery.
Breach notification: Require notification within 24-48 hours of discovering a breach affecting your data. Define what constitutes a "breach" broadly to include unauthorized access, not just confirmed data theft.
Right to audit: Reserve the right to audit the vendor's security controls, either directly or through a qualified third party. Annual audit rights for critical vendors.
Subprocessor management: Require notification before the vendor engages new subprocessors. Reserve the right to object to subprocessors that do not meet your security requirements.
Data return and deletion: Upon termination, the vendor must return all data in a standard format and certify destruction of all copies within 30 days.
Security standards: Require maintenance of specific certifications (SOC 2, ISO 27001) and define consequences for losing certification.
Insurance: Require cyber liability insurance with minimum coverage amounts proportional to the data risk.
Indemnification: The vendor indemnifies you for losses resulting from their security failures or breaches.
SLAs for security: Define maximum response times for security patches (critical: 24 hours, high: 72 hours), vulnerability remediation, and incident response.

For SOC 2 compliance, vendor contract requirements are a critical control area. Auditors will review whether your vendor agreements include adequate security terms and whether you enforce them.

Ongoing Vendor Monitoring

A point-in-time assessment tells you the vendor's security posture on the day they filled out the questionnaire. Continuous monitoring tells you whether that posture is maintained.

Continuous Monitoring Methods

Security rating platforms: SecurityScorecard, BitSight, and UpGuard provide continuous external security scoring for vendors. Set alerts for rating drops.
Breach monitoring: Subscribe to breach notification services and monitor news for vendor-related incidents. Use our Exposure Checker to verify whether your data appears in known breaches.
Certificate monitoring: Track vendor SSL/TLS certificate expiration and configuration changes. Expired or misconfigured certificates indicate operational security gaps.
Compliance monitoring: Verify that vendor certifications remain current. SOC 2 reports are issued annually — request the latest report each year.
Performance monitoring: Track vendor uptime, security incident reports, and response times for security issues. Degradation in any of these is a leading indicator of security risk.

Risk-Based Monitoring Schedule

Activity	Critical Vendors	High Vendors	Medium/Low Vendors
Security rating check	Monthly	Quarterly	Semi-annually
Full reassessment	Annually	Every 18 months	At renewal
Certification verification	Quarterly	Semi-annually	Annually
Breach monitoring	Continuous	Continuous	Monthly
Contract review	Annually	At renewal	At renewal

Vendor Offboarding Security Checklist

Vendor relationships end. When they do, the offboarding process is just as security-critical as the onboarding process. A vendor who retains your data after termination is an unmonitored risk that you may not discover until a breach notification arrives.

Revoke all API keys, access tokens, and credentials issued to the vendor
Disable SSO/SAML integrations and remove the vendor from your identity provider
Revoke network access (VPN accounts, firewall rules, IP whitelists)
Request written confirmation of data deletion from the vendor, including backups
Verify data deletion through a sample data retrieval test (attempt to access previously shared data through the vendor's API or interface)
Remove the vendor's subprocessors from your data processing records
Update your vendor inventory and risk register
Rotate any shared credentials or API keys that the vendor had access to
Review and close any open security issues or remediation items associated with the vendor
Archive the vendor's assessment records, contract, and correspondence for the retention period required by your compliance framework
Notify internal stakeholders who interacted with the vendor that the relationship has ended and access has been revoked

For a comprehensive approach to assessing your organization's overall risk posture including vendor risk, see our cybersecurity risk assessment template. For protecting against vendor compromise through the software supply chain, review our supply chain attack prevention guide.

Frequently Asked Questions

How do you assess a vendor's security posture?

Start with three layers of assessment. First, request compliance certifications (SOC 2 Type II, ISO 27001, PCI DSS) as baseline evidence. Second, send a security questionnaire covering encryption, access controls, incident response, data handling, and employee security practices. Third, perform technical validation: review their SSL/TLS configuration, check for known vulnerabilities in their public-facing infrastructure, verify their data encryption claims, and request penetration test reports. For critical vendors, consider a right-to-audit clause that allows you to conduct your own assessment of their environment.

What questions should be on a vendor security questionnaire?

A comprehensive vendor security questionnaire should cover: encryption practices (at rest and in transit, key management), access control (authentication methods, MFA enforcement, privileged access management), data handling (classification, retention, deletion, cross-border transfers), incident response (breach notification timelines, response plan maturity), employee security (background checks, security training, termination procedures), infrastructure security (patching cadence, vulnerability management, network segmentation), business continuity (disaster recovery, RTO/RPO, backup testing), subprocessor management (who else touches your data), and compliance (certifications held, audit frequency, remediation tracking).

How often should vendor security be reassessed?

Reassessment frequency should be risk-based. Critical vendors (those with access to sensitive data, production systems, or customer PII) should be reassessed annually with continuous monitoring between assessments. High-risk vendors should be reassessed every 12 to 18 months. Medium and low-risk vendors can be reassessed every 24 months. However, any vendor should be immediately reassessed after a reported breach, a significant change in their service scope, a change in their ownership or leadership, or when they fail to maintain required certifications.

The Bottom Line

Vendor security assessment is not a one-time checkbox exercise. It is an ongoing program that scales with your vendor portfolio and adapts to the evolving threat landscape. The organizations that do this well use risk-based tiering to focus their assessment resources where they matter most, enforce security requirements through contracts with real consequences, and continuously monitor their vendor ecosystem for changes in risk posture.

Start by building your vendor inventory — you cannot assess what you do not know about. Tier your vendors by risk. Apply the questionnaire template in this guide to your critical and high-risk vendors. And build offboarding into every vendor relationship from the beginning, because the hardest time to negotiate data deletion rights is after the relationship has already soured.

For related frameworks, review our SOC 2 compliance checklist, cybersecurity risk assessment template, and supply chain attack prevention guide.

Written by Usman Khan

DevOps Engineer | MSc Cybersecurity | CEH | AWS Solutions Architect

Usman has 10+ years of experience securing enterprise infrastructure, managing high-traffic servers, and building zero-knowledge security tools. Read more about the author.