Third-Party Vendor Security Assessment: How to Evaluate SaaS and Software Vendors Before Granting Data Access
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Supply chain security incidents are consistently among the most damaging class of incidents — they are high-impact because they affect all of the victim organization's customers simultaneously, and they are difficult to detect because the attacker's activity occurs in the vendor's environment rather than the victim's. The SolarWinds, Okta, and MOVEit breaches were all vendor compromise incidents that affected organizations that had done nothing wrong in their own environments.
The vendor security assessment is the control that reduces this risk before access is granted. It is not a guarantee — a vendor with a clean SOC 2 can still have a breach — but it identifies vendors with significant gaps that would make a breach more likely or more impactful, and it creates contractual requirements that ensure notification when a breach does occur.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Building a scalable vendor assessment program
The assessment process that evaluates every vendor with the same depth is unsustainable at any meaningful vendor count. The process that scales correctly applies assessment depth proportional to the risk each vendor represents, driven by a brief intake questionnaire that acts as a procurement gate before any vendor contract is signed. The intake questionnaire captures four data points: does the vendor process personal data, does the vendor have API or network access to internal systems, does the vendor handle financial data, and how many records will the vendor access. These answers determine the tier automatically, which determines the required documentation set and contract terms before procurement can proceed. The resulting vendor inventory, updated quarterly, also satisfies the vendor list request that auditors make during SOC 2 and ISO 27001 audits.
Create a vendor intake questionnaire that triggers tiering
Before procurement engages any new vendor: require a brief intake questionnaire completed by the business owner requesting the tool. Required fields: vendor name, product category, does the vendor process personal data?, does the vendor have API access to internal systems?, does the vendor have access to financial data?, estimated number of records the vendor will access. The answers determine the tier automatically: any 'yes' to data access questions = Tier 1 or 2 based on data sensitivity. The intake questionnaire creates a procurement gate — no new vendor contracts can be signed until the security assessment appropriate to the tier is completed. This prevents the common failure mode of the legal team signing a vendor contract before security has reviewed it.
Maintain a vendor inventory with assessment status
Track all active vendors in a spreadsheet or GRC platform with: vendor name, tier, last assessment date, next assessment due date, SOC 2 report date, any open exceptions from the last assessment. Review this inventory quarterly with the procurement team to identify: vendors whose SOC 2 reports have expired (more than 12 months old), Tier 1 vendors who have not been reassessed in 12 months, and new vendors added without completing the intake questionnaire. The inventory also provides the vendor list that auditors request during SOC 2 and ISO 27001 audits — having it pre-populated saves significant time during audit preparation.
The bottom line
Third-party vendor security assessment is the control that determines your supply chain risk exposure before access is granted. The risk-based tiering approach makes the program sustainable: Tier 1 vendors who process sensitive data receive full SOC 2 review, questionnaire analysis, and contract negotiation; Tier 3 vendors with no data access receive minimal assessment. The documentation request (SOC 2 Type II, pen test summary, incident history) and contractual requirements (DPA, breach notification SLA, right to audit) are the levers you have before contract signature — after the contract is signed and data access is granted, your leverage is significantly reduced. Build the intake questionnaire and vendor inventory before the next vendor assessment — the infrastructure makes future assessments systematic rather than reactive.
Frequently asked questions
How do I tier vendors by risk level to make security assessments scalable?
Vendor risk tiering framework: Tier 1 (High Risk) — full security assessment required: vendors who (a) process, store, or transmit sensitive data (PII, PHI, PCI data, intellectual property), (b) have direct API or network access to production systems, (c) have privileged access credentials to your environment, or (d) provide security tools or infrastructure components. Assessment depth: SOC 2 Type II review, security questionnaire, contract negotiation, annual reassessment. Tier 2 (Medium Risk) — standard assessment: vendors who (a) access non-sensitive business data, (b) provide integrated tools that access read-only internal data, (c) are cloud services where your data is in a dedicated tenant with no production access. Assessment depth: SOC 2 attestation confirmation, abbreviated questionnaire, DPA review, biennial reassessment. Tier 3 (Low Risk) — minimal assessment: vendors who (a) provide non-integrated tools with no data access (standalone SaaS tools that employees use directly), (b) public cloud services used for non-sensitive data, (c) hardware vendors with no data access. Assessment depth: confirm existence of security program (website review of security page), standard contract terms, no scheduled reassessment unless scope changes.
What documentation should I request from a Tier 1 vendor?
Tier 1 vendor documentation request list: (1) SOC 2 Type II report (most recent, within 12 months): the full report if possible, or a bridge letter from the auditor confirming no material changes since the last report if more than 6 months old. (2) Penetration test executive summary: test date, scope, testing firm, and high-level finding classification (number of critical/high/medium findings and their remediation status). Not the full report — vendors do not share full pen test reports, and the summary provides adequate visibility. (3) ISO 27001 certificate (if applicable): the certificate with scope and expiry date. (4) Security questionnaire responses: a completed SIG (Shared Information Gathering), CAIQ (Cloud Security Alliance Consensus Assessment Initiative Questionnaire), or your organization's custom questionnaire. The SIG is the most comprehensive standard questionnaire; the CAIQ is best for cloud services. (5) Subprocessor list: the list of third parties the vendor uses to process your data (their AWS hosting, their payment processor, their support ticketing tool that may contain your data). (6) Data breach/incident history: have they had a breach in the last 3 years? If so, what data was affected and what was the response timeline? This question is uncomfortable but necessary for Tier 1 vendors.
How do I read a SOC 2 Type II report to evaluate a vendor?
SOC 2 Type II report review process: (1) Check the opinion: the first page contains the auditor's opinion. 'Unqualified' (clean) opinion means no material exceptions. 'Qualified' opinion means material exceptions were found — this requires specific investigation. (2) Check the scope and trust service criteria: the report specifies which criteria were tested (Security, Availability, Confidentiality, Privacy, Processing Integrity) and the specific systems in scope. A report that only covers the vendor's corporate IT and not their production SaaS platform is limited in value. (3) Review the description of the system: the vendor provides a description of their infrastructure, access controls, and security procedures. Read this for accuracy against what the vendor has told you. (4) Review the complementary user entity controls (CUECs): these are controls that the auditor says YOU (the customer) need to implement for the service to be secure. If a CUEC requires you to enforce MFA on all user accounts and you do not, the SOC 2 does not provide the protection it implies. (5) Review the control activities and test procedures: for each control, the auditor's test procedure and result are listed. Look for any exceptions — a finding that the auditor tested 25 access provisioning events and found 3 where access was not properly approved is meaningful. (6) Check the report date and period: a SOC 2 Type II covers a 6-12 month period. A report dated more than 12 months ago is stale.
What contractual security terms should I require from Tier 1 vendors?
Required contractual security terms for Tier 1 vendors: (1) Data Processing Agreement (DPA): defines the purpose and legal basis for processing your data, prohibits the vendor from using your data for their own purposes (advertising, model training), lists their subprocessors, and specifies data deletion obligations upon termination. (2) Security incident notification: the vendor must notify you of a security incident affecting your data within a specified timeframe — 72 hours is the GDPR requirement and a reasonable commercial standard. Many vendor contracts default to 'prompt notification' with no defined timeline — require a specific timeframe. (3) Minimum security requirements: require that the vendor maintain: encryption at rest and in transit, MFA for access to your data, annual penetration testing, and access control limiting access to your data to vendor personnel who require it for their role. (4) Right to audit (or audit letter): the right to request an audit of the vendor's security controls, or at minimum a right to receive the annual audit report (SOC 2 or equivalent). (5) Data residency: if your compliance requirements or data regulations require data to remain in specific geographic regions, specify this. (6) Termination and data deletion: upon contract termination, the vendor must delete your data within a specified timeframe (30 days is common) and provide written confirmation of deletion.
How do I handle a vendor who cannot provide SOC 2 documentation?
Handling vendors without SOC 2 or equivalent documentation: (1) Assess why: is the vendor small (under 20 employees) and pre-SOC 2? Mid-sized but in an industry where SOC 2 is not standard? Or large enough that the absence of SOC 2 is a red flag? (2) For small/early-stage vendors: request their security questionnaire responses, ask about specific controls (do they have MFA enforced? Do they encrypt data at rest? Have they had a pen test?), and review their security policy if they have one. Small vendors can have good security posture without formal certification. (3) Ask for compensating evidence: a vendor without SOC 2 can still provide evidence of security practice: pen test report from a reputable firm, annual security training completion records, vulnerability management program evidence, or a letter from their CEO/CTO attesting to specific controls. (4) Accept with documented risk: if the vendor provides a critical service that has no SOC 2-certified alternative, document the risk acceptance decision with: the risk owner's name, the compensating controls reviewed, and a plan to reassess if the vendor has not achieved SOC 2 within 12 months. (5) Require SOC 2 achievement as a contract milestone: in the contract, specify that the vendor must achieve SOC 2 Type II within 18 months of contract signing as a condition of renewal.
How do I monitor vendor security posture after the initial assessment?
Ongoing vendor security monitoring: (1) Annual SOC 2 review: request the updated SOC 2 Type II report annually. Track the date of each report and proactively request the new report 12 months after the previous one. Set a calendar reminder 11 months after the previous report date. (2) Security incident monitoring: subscribe to the vendor's status page (status.vendor.com) and their security advisory mailing list if they have one. Monitor for public breach disclosures via HaveIBeenPwned (for consumer credential breaches), Google alerts on the vendor name + 'breach' or 'security incident,' and your threat intelligence feeds. (3) Attack surface monitoring: if you use a tool like SecurityScorecard, Bitsight, or Panorays, enroll Tier 1 vendors in continuous assessment — these services scan vendors' external-facing systems for security signals and alert you to changes (new vulnerabilities, expired certificates, DNS changes suggesting a subdomain takeover, etc.). (4) Contract renewal review: at each contract renewal, request updated documentation and verify that the vendor's security posture has not deteriorated since the last assessment.
What should I do when a vendor has a security breach that affects my organization's data?
Vendor breach response: (1) Immediately upon notification: contact your legal team to understand notification obligations — if the vendor's breach exposed personal data of your customers, you may have notification obligations to regulators (GDPR 72 hours, state breach notification laws) and to affected individuals. (2) Request specific information from the vendor: what data was affected (specifically, was your organization's data in the affected system?), the timeline of the breach (when did it start, when was it detected, when was it contained?), whether your data was accessed or exfiltrated (versus the breach affecting a different tenant), and the remediation actions taken. (3) Assess impact on your environment: if the vendor had API keys or OAuth tokens with access to your systems, rotate those credentials immediately as a precaution. If the vendor had access to employee credentials, force password resets and review authentication logs for suspicious activity using those credentials. (4) Document everything: retain all communications with the vendor about the breach for legal and regulatory purposes. (5) Review the vendor relationship: was the breach caused by a control gap that your pre-contract assessment should have identified? Update your assessment framework for future vendor evaluations based on the lessons learned.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.