Every technology vendor you buy from becomes an extension of your security posture. Their breach becomes your breach notification, their misconfigured storage becomes your data exposure, their compromised update pipeline becomes your incident. A vendor security review — sometimes called a third-party risk assessment — is the buyer’s process for evaluating a supplier’s security controls before signing, and for monitoring them afterwards. Done well, it is proportionate, evidence-based, and focused on the risks that actually matter. Done poorly, it is a 300-question questionnaire sent to every vendor regardless of risk, answered with boilerplate, and filed unread.

This guide is written for the buying side: technology leaders, security teams, and procurement partners who need to assess suppliers without grinding every purchase to a halt. It covers how to tier vendors by risk, which questionnaires to use and how to read the answers, how to interpret SOC 2 reports and ISO 27001 certificates, what to expect from penetration testing, how to handle data residency and subprocessors, which contract terms to insist on, and how to track remediation when vendors fall short. (For how security assessment fits into the overall selection decision, see our vendor selection scorecard guide. For the governance controls AI systems specifically require, see our AI governance guide.)

Tier vendors by risk before you assess anything

The foundational mistake in vendor security review is treating all vendors alike. A payroll processor holding your employees’ banking details and a project-management tool holding task titles do not deserve the same scrutiny — but many organizations send both the same questionnaire, waste weeks on the low-risk review, and under-resource the high-risk one. Risk tiering — assigning each vendor an assessment depth based on the risk it poses — is what makes the whole process sustainable.

Tier on two axes: data access (what the vendor can see, store, or process) and criticality (what breaks if the vendor fails or is compromised). A practical three-tier model:

Tier 1 — High risk. Vendors with access to sensitive data (customer personal data, financial records, health information, credentials, source code) or whose failure would halt critical operations. Expect: full security questionnaire, review of SOC 2 Type II report or equivalent, evidence of penetration testing, contractual security terms, and ongoing monitoring.
Tier 2 — Moderate risk. Vendors with access to internal-but-not-sensitive data, or important-but-replaceable operational roles. Expect: standardized questionnaire (SIG Lite or equivalent), review of available certifications, standard contractual terms.
Tier 3 — Low risk. Vendors with no meaningful data access and no operational criticality — a public-data lookup service, a commodity tool with no integration. Expect: lightweight due diligence, standard contract language, no deep review.

Tier at intake — when the purchase is first proposed — not after the contract is signed. The tier determines the assessment path, the timeline, and who needs to be involved.

Security questionnaires: which one, and how to read the answers

Two standardized frameworks dominate, and using them instead of a homegrown questionnaire saves everyone time:

SIG Lite (Standardized Information Gathering, Lite version) — a condensed, widely recognized questionnaire covering core security domains. Appropriate for Tier 2 vendors and as a screening tool for Tier 1.
CAIQ (Consensus Assessments Initiative Questionnaire) — focused on cloud security, aligned to cloud-specific controls. The natural choice for cloud and SaaS vendors.

For Tier 1 vendors, the full SIG or a tailored deep-dive questionnaire may be warranted — but tailor it. Sending 800 generic questions produces 800 generic answers. Focus custom questions on your specific risks: if the vendor will hold regulated data, ask about the specific regulatory controls; if the vendor integrates deeply with your environment, ask about their SDLC and change management.

Reading the answers is a skill. Watch for these patterns:

Boilerplate without evidence. “We take security seriously” and “we follow industry best practices” are not answers. Push for specifics: which practices, implemented how, verified by whom, and when.
“N/A” on questions that clearly apply. A SaaS vendor marking encryption questions N/A is either misunderstanding the questionnaire or hoping you are not reading it. Either way, follow up.
Inconsistency with other artifacts. If the questionnaire claims annual penetration tests but the vendor cannot produce a recent test summary, believe the missing evidence, not the checked box.
Overly narrow scoping. Answers that describe security for one product while you are buying a different one, or that cover the corporate network but not the multi-tenant production environment. Confirm the scope matches what you are actually purchasing.

Treat questionnaire responses as claims to be verified against independent evidence — certifications, audit reports, test results — not as conclusions. The questionnaire tells you what to verify; the artifacts tell you whether it is true.

Interpreting SOC 2 Type II reports

A SOC 2 report is an independent auditor’s assessment of a service organization’s controls against defined trust criteria — security, availability, processing integrity, confidentiality, and privacy. Type II means the auditor tested that the controls operated effectively over a period of time (typically 6–12 months), as opposed to Type I, which only assesses whether controls were suitably designed at a single point in time. For vendor assessment, Type II is the meaningful one: design without operating effectiveness is a policy binder, not a security program.

When a vendor provides a SOC 2 Type II report, read it — actually read it — with attention to five things:

The audit period and report date. A report covering a period that ended eighteen months ago describes a different company than the one you are evaluating. Ask for the most recent report and the bridge letter covering the gap period.
The scope: which systems and services. Confirm the report covers the specific product you are buying, not just the vendor’s corporate IT or a different product line. Multi-product vendors sometimes hold a SOC 2 for one flagship product while selling you another.
Exceptions and qualifications. The auditor’s testing results section lists controls that failed or had exceptions. A clean report with no exceptions is ideal but uncommon; what matters is the nature and severity of the exceptions and whether the vendor remediated them. An exception on timely access revocation for terminated employees is a different matter than an exception on backup testing — read them as a security practitioner, not as a checkbox.
Complementary user entity controls. SOC 2 reports routinely state that certain controls are the customer’s responsibility — configuring access correctly, managing your own users, enabling optional security features. These are not footnotes; they are your to-do list. If the report assumes you will enforce MFA on your side and you do not, the control environment the report describes does not exist in your deployment.
The auditor. A report from a reputable, established audit firm carries more weight than one from an unknown shop. This is not snobbery — audit quality varies, and the firm’s reputation is a proxy for the rigor of the testing.

A SOC 2 report is strong evidence of a functioning control environment, but it is not a substitute for assessing the risks specific to your use case.

ISO 27001 and other certifications

ISO 27001 certifies that an organization operates an information security management system (ISMS) meeting the standard’s requirements — it is about the management system, verified by an accredited certification body. When evaluating a vendor’s ISO 27001 certificate, verify three things: that the certificate is current and issued by an accredited body (certificates from non-accredited issuers are decorative), that the scope statement covers the services you are buying, and the statement of applicability — which controls the vendor included and, importantly, which it excluded and why.

Other certifications worth understanding at a high level: ISO 27701 extends the ISMS to privacy management — relevant when the vendor processes personal data. PCI DSS matters if the vendor handles payment card data; confirm the level and that it covers the relevant environment. CSA STAR builds on ISO 27001 with cloud-specific criteria. Industry-specific frameworks — HIPAA-aligned controls for health data, financial-sector regulatory expectations — apply where your regulatory environment demands them.

The general principle: a certification’s value depends entirely on scope, currency, and the credibility of the issuer. A current, well-scoped certification from a credible body meaningfully reduces what you need to verify yourself.

Penetration tests and vulnerability management

For Tier 1 vendors, ask about penetration testing — independent, adversarial testing of the vendor’s systems. What you want to see: tests performed at least annually by a qualified independent firm (not the vendor’s own team testing its own work), covering the production environment for the product you are buying, with a recent date. Ask for an executive summary or attestation letter — most vendors will not share the full report, and the summary plus a remediation statement is sufficient for assessment purposes.

What matters more than the test itself is the remediation story: what was found, what severity, and how quickly critical and high findings were fixed. A vendor that found three critical issues and remediated them in two weeks demonstrates a healthier security program than a vendor that claims its test found nothing — because no competent test of a real system finds nothing, and the claim suggests either a weak test or selective reporting.

Beyond point-in-time testing, ask about the vendor’s ongoing vulnerability management: how they track vulnerabilities, their patching cadence for critical issues, and whether they operate a vulnerability disclosure program.

Data handling: residency, subprocessors, and access

Data questions are where vendor security reviews most directly protect the buyer, because data mishandling is the failure mode with the clearest legal and reputational consequences:

Data residency and sovereignty. Where does your data physically reside, and where can it be accessed from? Confirm the vendor can commit to specific regions — not just “we use data centers worldwide” — and understand what happens during failover, support access, and analytics processing. If your regulatory environment or customer contracts require data to stay in a jurisdiction, get the commitment in the contract, not in a sales conversation.
Subprocessors. Most vendors rely on other companies — cloud infrastructure providers, analytics services, support tooling — that will touch your data. Require a current subprocessor list, notification before new subprocessors are added (with a right to object), and flow-down of equivalent protections. A vendor whose subprocessor list is “available on request” and three years out of date is not managing this.
Encryption. Data encrypted in transit (TLS) and at rest (AES-256 or equivalent) is table stakes. The questions that differentiate: who holds the encryption keys, whether customer-managed keys are available for sensitive deployments, and how key rotation and revocation work.
Access controls. Who at the vendor can access your data, under what authorization, and is that access logged and reviewed? Look for least-privilege access, MFA on administrative access, and evidence that access is revoked when employees leave or change roles. “Our engineers can access customer data to troubleshoot” without further qualification is a finding, not an answer.
Data retention and deletion. How long is your data retained, in backups as well as primary systems, and what happens on termination? Get deletion timelines committed in the contract.

Contract terms: incidents, audit rights, and exit

The security review’s findings should land in the contract, where they become obligations rather than observations. The terms that matter most:

Incident notification. A defined timeframe for notifying you of security incidents affecting your data — 48 to 72 hours is a common commercial standard. Define what counts as a notifiable incident, who notifies whom, and what the notification includes.
Audit rights. The right to audit the vendor’s relevant controls — directly or through an independent auditor — particularly after an incident or when certifications lapse. Most vendors will negotiate the mechanics (notice periods, frequency, who pays), but resistance to any audit right from a Tier 1 vendor is itself a signal.
Security commitments as warranties. The vendor’s key security claims — encryption standards, access controls, subprocessor management — stated as contractual commitments, not marketing. If a claim is true, the vendor can warrant it; reluctance to warrant a claimed control suggests the claim is softer than presented.
Termination for security cause. The right to terminate if the vendor suffers a material security incident, fails to remediate critical findings within agreed timeframes, or loses a certification it warranted. Pair with data return and deletion obligations on exit.
Liability. Ensure the limitation of liability does not render the security commitments meaningless. A vendor that warrants its security controls but caps liability for breaching them at twelve months of fees has priced the warranty at nearly zero. Push for carve-outs for data breaches and confidentiality violations, or at minimum a liability cap that reflects the actual exposure.

Negotiate these terms during selection, while competing vendors give you leverage — not after you have chosen, when the vendor knows the deal is theirs to lose.

Remediation tracking and ongoing monitoring

A security review that ends at signature is a snapshot, not a program. Findings from the assessment — missing certifications, weak incident-notification language, subprocessors to be disclosed — should become a remediation tracker with owners, deadlines, and consequences. Some findings are pre-signature requirements (a Tier 1 vendor without incident-notification terms does not get signed until the terms exist); others can be post-signature commitments with dates. The distinction should be explicit, not left to memory.

Ongoing, match monitoring to the tier. Tier 1 vendors deserve periodic re-assessment — annually at minimum — plus continuous signals: certification renewals, notification of material incidents, and review of subprocessor changes. Tier 2 vendors can be re-assessed on a longer cycle or on trigger events (renewal, scope change, reported incident). Tier 3 vendors need no ongoing program beyond standard contract management.

Putting it into practice

Vendor security reviews work when they are proportionate to risk, grounded in verifiable evidence, and carried through into contracts and ongoing monitoring. Tier first, verify claims against artifacts, right-size the effort, and track what you find until it is fixed. The goal is not a perfect vendor — it does not exist — but a clear-eyed understanding of each supplier’s risks and contractual protections matched to them.

If your organization is building or maturing its third-party risk program — designing the tiering model, running assessments on critical suppliers, or negotiating security terms — experienced guidance can get the program credible quickly. Our technology advisory engagements include vendor risk and security assessment support, and our capabilities cover security architecture, risk management, and technology strategy. To discuss your vendor review program, contact us.

Vendor Security Reviews: A Buyer's Guide to Assessing Technology Suppliers